[smartpowerdir] Fwd: CSWG Architecture review task for PAP01

[Fred Baker <[e-mail]>]

Somebody care to tell me how best to incorporate this comment into draft-baker-ietf-core? 

Begin forwarded message:

> From: [e-mail]
> Date: September 8, 2010 2:38:45 AM GMT+09:00
> To: Multiple recipients of list <[e-mail]>
> Subject: Re: CSWG Architecture review task for PAP01
> Reply-To: [e-mail]
> 
> 
> Okay.  I've copied Fred as well.  From my role within AEP as the Cyber Security Systems Engineering and Architecture Team Lead for AEP's smart grid initiative, I have some issues with the direction this is leading. 
> 
> I've read and reviewed the draft IETF document.  My main issue with the discussion on security architecture is that people only think about the technology involved.  The technology discussion is really an issue that is TACTICAL in nature.  Security is less about the technology and more about the process.  What needs to be provided for is a security architecture that is STRATEGIC and HOLISTIC.  What I don't see are any provisions for addressing security processes, which could easily be provided for by using a "Systems Engineering" methodology for cyber security.  My recommendation is to use SSE-CMM (ISO/IEC 21827).  Please note:  Systems Engineering incorporates architecture work.   
> 
> If you look at a typical utility's internal environment, you can divide it up 5 areas, which can then be matched to the various security systems engineering needs: 
> 
>   
> 
> On the security architecture perspective, I still advocate the use of SABSA as a baseline measure of what needs to be included when discussing security architecture and the smart grid.  SABSA can work in conjunction with TOGAF, which I believe is what the SGIP SGAC has settled on - Sandy, correct me if I'm wrong. 
> 
> It sounds like what is being requested is more of a checklist approach and what is needed is really a holistic approach.  I'll use SABSA for my example.  SABSA, in defining a security architecture, asks the following questions: 
> Are the smart grid requirements understood?
> What is the design philosophy of the smart grid?
> Are all smart grid components identified and accounted for?
> Do the smart grid components work together?
> When the components are assembled as a system, is it an integrated smart grid system?
> Is there evidence provided to assure the smart grid system is properly assembled?
> Does the smart grid system run smoothly?
> Is the smart grid system tuned properly?
> Is the smart grid system being operated correctly?
> How is the smart grid system being maintained?
> 
> If you look at the SABSA model, there are six different views of security architecture.  They are: 
> The Smart Grid Business View --------------> Contextual Security Architecture
> The Smart Grid Architect's View -----------> Conceptual Security Architecture
> The Smart Grid Designer's View ------------> Logical Security Architecture
> The Smart Grid Builder's View -------------> Physical Security Architecture
> The Smart Grid Tradesman's View -----------> Component Security Architecture
> The Smart Grid Facilities Manager's View --> Operational Security Architecture
> 
> Since what the NIST SGIP is trying to do is to provide a baseline approach to interoperability and cyber security for the smart grid, I would approach this entire topic using a project management methodology, somewhat along the lines of the PDIM, Plan-Design-Implement-Manage method.  I don't think this is being done right now.  From a SSE-CMM perspective, there are the following high-level major phases of work that need to be reviewed: 
> Security Risk Assessment        
> Discover Information Protection Needs
> Define System Security Requirements
> Define System Security Architecture
> Develop Detailed Security Design
> Implement System Security
> Assess Security Effectiveness
> 
> To date, we have not really provided a security architecture for the smart grid, which was really outside of our NIST defined scope.  It's more of an interface to interface design and not a systems security architecture for end-to-end effectiveness.  The framework provided for by the SABSA model would allow for a more holistic approach to ensuring that the smart grid is protected from any number of threats and vulnerabilities.   
> 
> Neil 
> 
>  
> 
> 
> Sandy Bacik <[e-mail]> 
> Sent by: [e-mail]
> 09/06/10 01:34 PM
> Please respond to
> [e-mail]
> 
> To
> Multiple recipients of list <[e-mail]>
> cc
> Subject
> CSWG Architecture review task for PAP01
> 
> 
> 
> 
> 
> Good day everyone, 
>   
> I have a task for us to do. Fred Baker is working on the SGIP PAP01, a communications architecture to support the SGAC's business architecture. He would like comments on how it relates to the NISTIR and our thoughts on security. You can read the current version in http://tools.ietf.org/html/draft-baker-ietf-core-07#section-2. You can either respond to me and I will forward the comments onto Fred or you can email Fred ([e-mail]) directly with your comments. Because PAP01 is meeting in St. Louis, the comments need to be back by Friday, September 10, 2010. 
>   
> From Fred’s perspective, the security angle of a communications architecture has several major components:
> in anything resembling a public network, such as the HAN or NAN, it is important to know that communicants using network bandwidth are authorized participants in the network. IEEE 802.1X+EAP-TLS, as proposed in Zigbee SEP 2.0, is a reasonable response to that.
> in any network, AAA issues are important. In IP networks, we can discuss IPsec (transport or tunnel mode, basically authorizing systems to communicate with optional encryption) or TLS and its cousins (authorizing applications to communicate, with optional encryption)
> if data is relayed end to end through intermediaries, one needs to understand why the intermediaries are trusted. That might mean signatures on data elements that are relayed (think DKIM, RFC 5585, W3C XML signatures, or what has been proposed in routing as described by RFC 2154 or SBGP). If the intermediary is part of a distributed application as as such summarizes downstream information, it is its own data source/sink as well.
> people will hack into any network. Smart Grid Meters, for example, can be hacked into by using their firmware download
> capabilities to download attack firmware. Part of the question is how to detect compromised systems and exclude them from the flow of data, preventing them from injecting it and not routing other data through them.
>   
> If there are any questions, please do not hesitate to contact me. 
>   
> Regards, 
> Sandy Bacik, CISSP, ISSMP, CISM, CGEIT 
> Principal Consultant, EnerNex 
> [e-mail] | (C) 865-696-4470 | www.enernex.com 
> 620 Mabry Hood Road, Suite 300 | Knoxville, TN 37932 
>   
>   
>