Merry Christmas and a Happy New Year!

MERRY CHRISTMAS!

Is it really AI?

We do read a lot about Artificial Intelligence (AI) these days. AI seems to get in nearly everything. Just pick the right chip and you can put the AI sticker on your product. But is it really that easy? Where is the difference between AI and Machine Learning? And, is the term Intelligence the correct notion anyhow to describe a computer based system? Is it a qualitative or quantitative property?
Depending on the answer, is it something we can measure?

Would it be feasible to create a questionnaire for machines to found out about AI?

Happy New Year! 
Alles Gute für 2013, Gesundheit, Glück und Erfolg!

Security Architecture – moving forward with an approach to outline a framework

It is a key success criteria in system development and architecture to improve and extend models, procedures and underlying frameworks. This is especially needed when it comes to cyber security of complex systems. I started recently to improve my framework for a robust security architecture. Many stakeholders tend to start with the details in such complex systems which may result in missing overall requirements and ramifications. Security in the scope of vast, distributed systems needs to be specified, designed, implemented and operated based on a solid framework – let’s call it a Security Architecture. I have seen many approaches in order to cover this tricky task. Many of them tend to be too complex. Unfortunately, complexity is not a driver for security (in contrast to simplicity). On the other hand, it’s a tough job to keep the Security Architecture for huge systems simple. Beside the need for a simple approach, transparency and clearness in the scope of Security Architecture are important attributes that should be addresses as key-objective. Security controls need to be structured and encapsulated in the relevant components of the Security Architecture in a clear and traceable manner. I prefer a structure consisting of the following main components:

1. Security Infrastructure [ Communication and Network Security, Perimeter Security, …]
2. System Security Services [ Access Control, Identity Management, Credential Management, Audit, Backup and Recovery, …]
3. Application Security [ Operation Systems, Databases, Web and Application Server, SaaS, Enterprise Applications, Collaboration, and Messaging, … ]
4. Service Security [ System Maintenance, System Operation, Change Management, Incident Management, Event Management and Forensics, Stakerholder & User Feedback, ...]
5. Security Management [ Policies and Roles, Risk Management, Training and Awareness, Secure Coding, Design Principles, Algorithms]
   

The components 1-4 are the basic layers of the Security Architecture. A more vertical component is Security Management which covers and affects all the other 4 essential parts of the Security Architecture.

Fachtagung Informationssicherheit im Netz- und Anlagenbetrieb der elektrischen Energieversorgung

TC 57 / WG 15 und IEC 62351
Intro

§ Die Working Group 15 (Data and Communication Security) ist im Rahmen des IEC innerhalb des TC 57 tätig.

§ Das TC 57 [Technical Committee] trägt den Titel “POWER SYSTEMS management and associated information exchange”.

§ Das TC 57 entwickelt internationale Standards für Energie-systeme (EMS, SCADA, DA, Teleprotection und andere):
http://tc57.iec.ch/index-tc57.html

§ Die WG 15 …

… hat ca. 55 Mitglieder und trifft sich zweimal im Jahr.

… ist für die Standards IEC 62351 (Part 1-8) federführend.

… ist für die Security von Protokollen innerhalb des TC 57 verantwortlich (z.B.: IEC 61850, ICCP/TASE.2).

… adressiert auch das Thema End-to-End Security!

TC 57 / WG 15 und IEC 62351
IEC 62351: Inhalt der Teile 1 bis 8 im Überblick

§ Part 1: Einführung (Übersicht zum Thema Cyber Security, Besonderheiten innerhalb der TC 57 Domäne)

§ Part 2: Begrifflichkeiten (Glossary, Ziel: besseres Verständnis basiert immer auf einheitlicher Terminologie)

§ Part 3: Security für Protokolle mit Profilen beruhend auf TCP/IP (z.B.: ICCP/TASE.2, IEC 61850 Client/Server)

§ Part 4: Security für Protokolle mit Profilen beruhend auf MMS [Manufacturing Messaging Specification] (z.B.: ICCP/TASE.2)

§ Part 5: Security für Protokolle der Reihe IEC 60870-5 u. Derivate

§ Part 6: Security für IEC 61850 (GOOSE, SV, MMS), SNTP (RFC 2030) und VLAN [Virtual Local Area Network] Technologien

§ Part 7: Security MIB’s [Management Information Base] für Netzwerk- und Systemmanagement (à TC 57 spezifische MIBs)

§ Part 8: RBAC [Role Base Access Control] für Energiesysteme
(à Rechte, Rollen, Access Control)

TC 57 / WG 15 und IEC 62351
WG 15: Kooperation, Interaktion, Wahrnehmung

§ Die Standards der Reihe IEC 62351 werden in Dokumenten und anderen Standards als relevant für die Security in der Energieversorgung und im Rahmen von Smart Grids erwähnt (Beispiele: NIST, IEC SG3 Roadmap).

§ Das NIST hat IEC 62351 kommentiert (Änderungen erforderlich).

§ Das NIST hat FERC die IEC 62351 Standards als relevant für Cyber Security empfohlen.

§ Die Umsetzung in Produkten ist momentan eher überschaubar.

§ Es gibt eine Vielzahl von Kooperationen und Koordinationen mit anderen Organisationen (z.B.: IEEE, CIGRE, ISA, ISO, …).

§ Mitglieder der WG 15 arbeiten aktiv an Standards wie NERC CIP und NIST IR 7628 „Guidelines for Smart Grid Cyber Security” mit.

TC 57 / WG 15 und IEC 62351
WG 15: Aktivitäten und Ausblick

§ Mehrere Teile des Standards werden momentan überarbeitet und angepasst. (à Machbarkeit, Cipher Suites)

§ Die WG-15 spezifiziert die Security für den Standard 61850-90-5 (“Use of IEC 61850 to transmit synchrophasor information”) mit dem Ziel eines Technical Reports.

§ Die WG-15 arbeitet weiterhin an einem Technical Report (“Security Architecture Guidelines”).

§ Geplante Aktivitäten:

§ Der Teil 9 “Schlüsselmanagement” ist momentan im Status eines NWIP [New Work Item Proposal].

§ Unterstützung der WG-10 (à IED, IEC 61850) bei der Definition der “Security für System Management”.

§ Eventuell Unterstützung des NIST zum Thema “Security Requirements for Field-Deployed Devices” (à IED, Zähler)

TC 57 / WG 15 und IEC 62351
Finale

Vielen Dank für Ihre Aufmerksamkeit!

Dipl.-Ing. Maik G. Seewald

[maseewal@cisco.com]

Frankfurt am Main, 20-Januar-2011

Fachtagung Informationssicherheit im Netz- und Anlagenbetrieb der elektrischen Energieversorgung

§

Ein gesegnetes Weihnachtsfest!

Merry Christmas and Good Times in 2011!

Actually, it's winter time

It's autumn

River Elbe, October 2010 [webduke pics]

Security must be based on a solid (security) architecture

We can read a lot about vulnerabilities, malicious code and horrifying threat scenarios these days. And, we can also learn from all these experts how to fight this. Actually, there is nothing about war and weapons (that could help anyhow). Everything is about solid requirement management (covering security from the very beginning), a decent architecture as well as a design which addresses security seriously. Sure, the team must be qualified to handle this. Just some thoughts: A sustainable architecture is composed of discrete elements, called components. Components are the core parts of architecture. Their design and composition is essential to meet the requirement for a sustainable architecture. Beside these factors, security is another success criterion. Components must be secured in accordance with industry recommended practices. Design and implementation must adhere to security principles, design patterns and coding rules. They must be configured according to the security policies of the organization. This must apply for all components the architecture consists of. Remember the weakest link paradigm; one weak component could compromise the security of the whole architecture. Components which expose interfaces to the “outside world”, like user or communication interfaces are especially under attack or even the entry point for an intruder. This must be considered when specifying, designing and developing these entities. And, interfaces must be well-defined to support an integrative approach in order to achieve end-to-end security. The idea behind this is that a system that is composed of components must assure security when sending or receiving message from on or more component to another and even beyond the system.

Robustness and resilience of large distributed applications and networks

In the area of clouds and large distributed automation and control networks, we need to deal with a vast number of (growing) endpoints integrated in the (dynamic) system. It is probably a misconception to assume that all these peers could be protected comprehensively at any time. Hence, it must be an important objective that the protection of the entire system must not depend on the security status (pertaining integrity, confidentiality and availability) of each and every endpoint. In other words, a compromised node must not affect or infect the stability and protection of the entire distributed system. This shall be adressed in the system and security architecture and needs to be defined (and tested !) as a crucial requirement. A (layered) defense in depth, as a general design principle, can help to meet this requirement. In addition, intrusion detection, prevention and a quick isolation of the compromised node can help to minimize the overall impact. Plan for failure is the underlying principle to implement this efficiently. Beside these classical security precautions and controls, a robust design as well as adequate redandancy mechanisms for critical subsystems can support the system stability.

Security in large distributed networks (aka Smart Grids)

Security is not only a crucial requirement for conventional data and communication networks. It must be also addressed in networks that are installed and operated to automate and manage energy grids in order to achive a Smart Grid. Definitions may vary but the need for security in the area of critical infrastructures is undisputed. Beyond architecture and compliance, real implementation requirements exist. The paper Enhancing IEC 62351 to Improve Security for Energy Automation in Smart Grid Environments presented at the 2010 Fifth International Conference on Internet and Web Applications and Services in Barcelona provides insights.

Test your security!

Testing security of distributed systems is a very complex thing (sure, security is complex inherently). This is because of the nature of security requirements which is functional as well as non-functional. To meet such basket of requirements, good practise is highly recommended. The subsequent bullets list the necessary steps in a proposed order to achieve this goal:

• Document all functional and non-functional requirements and develop use case scenarios base on it (a picture helps a lot !)
• Invite security professionals for support and guidance
• Conduct a comprehensive threat assessment based on a well documented system architecture and (preferable) a security architecture (invite all relevant stakeholders: product management, architects, developer, test folks, …)
• The architecture must support flexible patch and update management
• Review the resulting design, at least the security relevant components
• Check on all 3rd party components in detail to identify known weaknesses; if so, look for alternatives
• Provide and teach (!) secure coding and secure design principles to the team
• Make sure that the team has enough time to learn and to apply such rules and principles (project management must plan accordingly!)
• Test all functional security requirements accoring to your test specification (use well documented requirements and use case scenarios to specify test cases)
• Use tools to check your code to identify flaws and derivations from your guidelines mentioned above
• Apply code review if tools are not sufficient
• Use a realistic test environment (set up) to run a kinda black box test based on tools (fuzzer, etc.)
• Test especially all user interface (focus on web based interfaces) as well as communication stacks
• Document all testing results and establish a rating based on criticality
• Communicate and share your experience

Divide and Protect

Divide and conquer is a well-know strategy in software design and architecture. In terms of OOA/OOD it is not really my favorite approach, but this is not the topic of this post.
Divide and protect is one option to secure large distributed systems. The concept of Divide and Protect is about the compartmentation of a system into functional blocks with identical requirements in terms of security and privacy. It supports a defense in depth strategy, and it helps to handle the complexity of large installations. The compartmentation of a given system leads to security zones with different levels of trust that should be outlined in a digram. Based on such diagram (red = not trusted, .., green = trusted), the system architecture can be developed in a comprehensive manner. This is especially true for the communication architecture and the selection of appropriate protocols. By using this approach, non-functional requirements can be addressed in the early beginning of the product development process which means no change (requests) later on.

Failure is an option

I read about a conference on failing in the Silicon Valley last year (and I was fascinated by this way of thinking immideately). Well, I think this approach to tackle issues and mistakes is one success criterion which makes this exceptional high-tech valley that successful. Ten years ago, I was lucky to work for one year in Santa Clara / Sunnyvale. At this time, the Silicon Valley was the epicentre of the internet boom. I learned a lot about trying out new things and to be innovative in thinking and developing systems. I need to mention from time to time that software development is still a heuristic process. There are no tools to produce exactly that result in terms of code which is intended in the phase of project initialization. It (the mother of all tools) has been promised for years but it has not arrived yet. Sure, there are patterns, models, code fragments, IDE’s and many other helpful things but in the end it is up to a human beeing (the engineer) to compose and develop the solution. And this still works by trial and error in many cases. The most important lesson is to accept failure and to learn from it. This sounds easier than done and means a learning process for the whole team. But this is absolutely necessary in order to handle the complexity of computer science these days in a professional manner. One of my methods to take care of this is to document alternative solutions (to the choosen way of implementing it) for a given project and to outline the reasons for discarding. As an easy rule of thumb: In order to develop solutions successfully, we need to learn how to fail in the right ways.

Success criterions for development projects

Many factors do impact the success of development projects these days, much more than a couple of years ago. I have learned to focus on a very limited number (3-4) of key objectives to achieve in large scale projects in order to stay on track. Key objectives are the principles of a project and should be well-know, understood and accepted within the project team. To miss even one of them means failure. If it comes to decision making, the key objectives build a good foundation to move forward. This is a proven approach for projects but also for the development process itself. Here are my four (4) key objectives for successful system development:

1. Precise, high quality requirements based on strong user involvement
2. A motivated and skilled team with the ability to learn constantly
3. Flexible and realistic project management
4. An open and innovative environment which understands the fact that software development is a heuristic process and which accepts failure
   

I don’t want to simplify system development. I do know that there are many other factors and ramifications. But people tend to get lost in too many details and micro-management tasks. Concentrating on the essentials does lead to successful development in a very complex world.

Security Architecture – an approach to outline a framework

Security in the scope of vast, distributed systems needs to be specified, designed, implemented and operated based on a solid framework – let’s call it a Security Architecture. I have seen many approaches in order to cover this tricky task. Many of them tend to be too complex. Unfortunately, complexity is not a driver for security (in contrast to simplicity). On the other hand, it’s a tough job to keep the Security Architecture for huge systems simple. Beside the need for a simple approach, transparency and clearness in the scope of Security Architecture are important attributes that should be addresses as key-objective. Security controls need to be structured and encapsulated in the relevant components of the Security Architecture in a clear and traceable manner. I prefer a structure consisting of the following main components:

1. Security Infrastructure [ Communication and Network Security, Perimeter Security, …]
2. System Security Services [ Access Control, Identity Management, Credential Management, Audit, Backup and Recovery, …]
3. Application Security [ Operation Systems, Databases, Web and Application Server, SaaS, Enterprise Applications, Collaboration, and Messaging, … ]
4. Service Security [ System Maintenance, System Operation, Change Management, Incident Management, Event Management and Forensics, …]
5. Security Management [ Policies and Roles, Risk Management, Training and Awareness, … ]
   

The components 1-4 are the basic layers of the Security Architecture. A more vertical component is Security Management which covers and affects all the other 4 essential parts of the Security Architecture.

Quality of Non-Functional Requirements

As already outlined, non-functional requirements are a crucial success criterion in distributed systems (and in software development in general). These requirements need to be prioritized in order to focus on the main use-cases of the system. Beside prioritization, using a clear syntax is important as well because non-functional requirements tend to be fuzzy. This limits the acceptance during development. Like their functional siblings, non-functional requirements should adhere to the following criterions as well:

• Clear and non-ambiguous
• Described by using simple and consistent terminology which is well-known by all stakeholders
• Testable at the end of the day in order to achieve a measurable outcome
• Traceable from the beginning until the end (architecture, design, implementation, test, roll-out)
• Technical feasible considering the tools and systems that are part of development and deployment scenario
• Realistic in realization which depends on the planning horizon, the skill-set and location(s) of the team, the infrastructure and the development environment
  

Ideally, a designated requirement manager and a software architect are the perfect team members to make this happen. All stakeholders should agree on this proceeding in the beginning and are asked to monitor the adherence over the whole lifetime. “Lessons learned” are a good approach to refine this process. Good and bad examples should be used to tune a successful requirement management to perfection.

Defeating OCSP – is it that ez?

Certificates in the scope of asymmetric cryptography are an approved means to achieve a solid state of security in many applications (using TLS/SSL predominantly). Options in this area of computer security are limited. Establishing trust and running a CA (Certificate Authority) is cumbersome and need a lot of resources. A widespread usage of certificates comes along with a higher number of revoked certificates that must be identified in order to deny access. Certificate revocation lists (CRL) and the OCSP (Online Certificate Status Protocol) are options to establish these check points. To keep CRL’s up-to-date and to handle their constant growth, is a well-known problem. OCSP provides this status on a server in a centralized approach. A check point (server, client, any consumer of a certificate) can ask the OCSP-server in order to make sure that the presented certificate is not revoked. But can we trust the response? Not in any case as we could learn from a security expert recently (check on heise security and other resources). ResponseData and ResponseStatus are different structures within the response but only ResponseData is covered by a signature. A faked response (by a running a man-in-the middle attack) could send a “tryLater” which is a valid status. It’s up the OCSP-implementation at the check point to handle this response properly. And. it’s up to you to imagine how this is handled in a real-world implementation. It’s a kinda scary if you can’t even trust a security service indented to provide “more security”.

More on Software Architecture – Architectural Styles

Our domain of software architecture is improving constantly and gets specified in more detail. This is not bad thing because it helps to avoid misconceptions about their place in software development. Architectural styles are one building block of the process in striving for the best fitting solution. Looking for analogies, ‘real architecture’ in terms of brick and mortar has a long history in architectural styles like Gothic, Tudor, Art Nouveau, or Postmodern. These styles are influenced by social, political, cultural and other trends. Of course, technical factors like material, technologies, infrastructure and appliances play an additional role (and money, of course). In software architecture, these factors are predominant. But trends and hypes play their role as well. SOA is a good example to illustrate this. In general, architectural styles can be clustered based on the part of the system they describe like structure [Component, Layered], deployment [Client-Server, n-Tier, Peer-to-Peer], communication patterns [Message Bus], and others. Sometimes it is hard to assign a style properly to cluster. Styles to handle user interaction [MVC] might be a part of the structure or could be seen as a separate cluster. But this is not important. More relevant is the process of combining styles in order to achieve the best solution. Some styles might be determined by the requirements directly. Hardware, integration of legacy system and other infrastructure related preconditions might limit the choice. Moreover, the skill set of the team is another factor. In general, functional and non-functional requirements should influence the architectural styles and their combination used to build the system (hypes should not btw.). If this is done properly, the benefits are proven patterns, a common understanding, interoperability and reuse. In other words, the combination of the best fitting architectural styles is a key success criterions in the process of building a software system.

Software based Transactional Memory

This is interesting news for C# developer. MSDN DevLabs offers the STM.NET as an extension to the .NET framework 4.0 (Beta 1) for experimental purposes. STM stands for Software Transactional Memory and provides support for concurrency in order to use the multi-core architecture efficiently. STM does not provide a lock framework. It comes with an approach to isolate shared state which is the real issue when it comes to concurrency (because of dead locks and/or race conditions). Based on the ‘transaction pattern’ used in other areas of computer science, code (and memory) is handled isolated to enable an atomic execution. Code sections are demarcated accordingly. It will be interesting to check on this, especially pertaining to performance implications. But anyhow, it might be a promising step, at least for the C# folks.