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.

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.

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.

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”.

Security in the scope of Software Architecture

Security must be addressed in the development very early. Taken existing and well-defined security requirements for granted, the system and software architecture (an artifact called “Architecture Specification”) must consider and reflect security. I do favor an approach based on a set of essential building blocks in order to achieve the expected level of security. Parts of the building set are:

• Secure Components
• Secure Infrastructure and Services
• Secure Execution Environment
• Secure Network Environment (zones, compartments, sandboxes)
• End-to-End Security (supported by services like identity, authentication, authorization, auditing)
• Secure Operation (Logging, Import/Export, Backup/Restore) and Security Appliances
  

The approach addresses common security paradigms like “Layered Defense”, “Security in Depth” as well as general design objectives (modularity, consistency, extensibility, robustness). These building blocks are the foundation for a security architecture where security controls can be applied. Just to drill a little bit down. Secure components can be characterized as in the following:

Design and composition of components are essential steps to meet the requirement for a sustainable architecture. Components must be secured in accordance with 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. Remember the weakest link paradigm; one weak component could compromise the security of the whole architecture. Components that 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 overall security requirements for the component design should be derived from general security objectives such confidentiality, integrity, availability, and accountability.

Identity is king

Many large distributed systems have on success criterion in common – identity (management). This is true for social networks (we all love to be part of), e-commerce platforms, systems operated in the clouds as well as for networks in the realm of automated demand/supply operation (aka Smart Grids). The requirements are not new at all: the identity of a large number of participants must be handled in a way that peers can trust each other based on one or more identity providers. Identity is needed for authentication in order to enforce access control to a resource (a website with profile information, a virtual shopping cart, a database table, a data point, whatever). It’s about the identity of the subject (the source) which has initiated the request to get access to a resource. Before the access rules can be applied (authorization), this authentication must be handled in a trustworthy way. This is complex to achieve, especially in case of multiple domains that operate their own realm of trust. This kind of trust is a precious thing that needs to be protected and maintained. Beside all theory and technical details, it (the precious thing of digital identities in an existing community) is an important asset. A social network identity could be used to get access granted to other resources like a virtual shopping mall or a booking engine for last minute flights. More scenarios are obvious ….

Computer Security in the scope Web 2.0

The current issue of ACM Queue puts Web Security in focus. One article is titled Cybercrime 2.0: When the Cloud Turns Dark. In essence, it is really hard to disagree. I could just add a couple of web attack scenarios based on update services or instant messaging. A lack of security in the design of web applications and the underlying infrastructure is the root cause, as stated in the conclusion of the article. But it is really hard to see some kind of remedy in the near future. On the contrary, new solutions like offline web-applications, cloud computing and the so called Web-OS are all based on vulnerable technologies but connect a large number of users and machines. This will increase the attack surface because each single hole in the system might give an attacker access to a large network of assets and services. Some people call these new applications and architecture already Web 3.0. Unfortunately, nothing has changed in terms of security.

Offline-Web Applications & Security

We can read a lot about Computing in the Clouds these days, even in ordinary newspapers. It’s a big business with SOME open questions. I started to compile a couple of thoughts in Web Browser, Web-OS and the Era of Cloud. Beside the real differences to Client-Server Computing (“Dude, sometimes I can spot them, and sometimes not!”), I do have my concerns pertaining to security. Take the so called Offline-Web Applications (sometimes called Web 3.0) for example. Beside the fact that this word is a contradiction in itself, the vulnerabilities are an existing problem. Running web servers everywhere increases the attack surface. The HTTP-servers on the client machines are needed to keep the applications (that are web applications) running in case of a network blackout. In addition, to maintain state is another must to allow a kinda real application feeling. Maintaining state in the scope of web application based on HTTP with all consequences has been a security problem from the beginning. Nowadays, state is maintained by using cookies and other remnants initiated and used by browsers and plug-ins. Talking about Offline-Web Applications, small databases on client-side are in use. But this list is not complete yet. HTML 5 specifies a Structured Client Side Storage which includes database storage (local and relational). Some Web-browser vendors are planning to support to a certain degree (session, local, database). This will change attack scenarios as well as attack surface. Combined with excessive scripting, but this is another story …

Security in Cloud Computing (Distributed Systems)

Security is one of the most important requirements to make a software system running in the cloud acceptable for the intended user community. This is especially true in times like this where people’s privacy is under attack on a daily basis. Just follow the news in Germany. It’s a big concern and not far fetched, not at all.
Computer security got a couple of basic pillars; Identity Management is one of them. In the new realm of cloud computing, this comes along with authentication and authorization in distributed systems. SAML (the SAML 2.0 protocol) and OpenID are more or less standards to support the implementation, also in terms of interoperability. Big vendor’s cloud architectures (just see the Geneva project as an example) do support these standards. This is not just a good approach in terms of interoperability; it also leads to a better understanding and visibility regarding the underlying implementation and infrastructure which probably leads to more trust and better acceptance.

A brief history of Access Control

Access Control is an important part of the computer security realm. It is complex, hard to achieve in a robust and bullet-proof manner and it will always screw up ordinary users that want to surf and play around without being confronted with nasty restrictions, decisions and limitations. Is this realistic, achievable? Well, everything seems to be a big loop in the computer and software industry [a reference to the good old times :-)]. Take the cloud-stuff as example. Sharing resources and deploying thin clients is not that new. Its just branded (and pushed) like a new hype. Where is the relation to access control? Access control can be implemented in the operating system (OS) as well as in other layers of the application stack. I’m gonna focus on the OS level here. I remember times [aka as the good old times :-)] where user-rights in terms of access control were very limited. The change came with the advent of personal computing. Everybody wants to be an admin (and can be an admin) very easily, even programmers. In case of a disconnected, single-user machine, it might not be a problem. But this is not a valid scenario. We want and need the Internet. Yes! But beside all the cool stuff, male-ware is everywhere, and needs our machines as host or target. We are easy prey when running everything as admin. So we need to get back to the good old times [in order to complete the loop:-)]. In Vista, a serious attempt has been started. It might be boring to get asked all the time when feeling like an admin (but just being a standard user for the process in execution which is the parent process for later stuff). And, it might be cumbersome to maintain the virtualized registries for the old programs. Security versus usability and maintainability, this is the battle that it is raging. It should be fought and security must prevail (in the era of identity theft, male-ware and root-kits); especially when everything is running in the clouds. Hopefully, smart people will come up with some smooth solutions that make limited user-rights in terms of access control more acceptable.

Security and Virtual Machines, Part II

I announced lately to get back to this virtual thing and the ramifications when talking about security. Here we go. Identity and ownership are important factors in the security realm. Both attributes are often handled different in the world of Virtual Machines (VM). The owner of the real box might not be the owner of the VM. Identifiers (port number, MAC address) can differ and old-fashioned identity-schemas can not be applied anymore. Another side-effect coming with VM’s is an increase of complexity for the patch and update management. This is because of the broad variety of operating systems and versions that can be installed (and that will be installed) on the top of VM’s. All of them got their own life-cycle and their security-patches that must be applied. The VM life-cycle which can be characterized by snapshots and rollbacks is definitely helpful for testing and other evaluation purposes. But there are operations in the area of cryptography that could suffer. Time, random numbers, seeds, initials vectors, transaction states – just to name a couple of potential vulnerabilities. I see some room for improvement, especially for randomness in a virtualized environment. This must be addressed in the scope of the security architecture for a given system.

Surf Globally, Store Locally?

The era of clouds (see my post on that) comes along with a lot of options to outsource data processing, storage and integration. Well, using external processing power is definitely a good idea, and this service is already accepted and used. Also the integration scenarios offer a lot of chances (beyond the market place and b2b capabilities). But storing data on external machines is a different thing. Security (privacy) concerns exist and should be taken seriously. Incidents (just see what happened to customer data of a big German telecom / mobile phone company) are no exceptional cases and the most spectacular are probably just the tip of the iceberg. Bullet-proof security architecture does not come for free. It’s expensive and a never ending process. Richard Stallmann (RMS) published his concerns last week. He called cloud computing a trap. His view is more about the fact that user might loosing control when running there applications in the clouds. This implies the security aspect. So, should the slogan of the environmentalists “buy locally” a little bit adapted in order to recommend a “store locally” approach?

Security and Virtual Machines

A lot of rumors are circling around that Virtual Machines (VM) could pose another threat to IT-Systems which use hypervisor-technologies extensively these days. Unfortunately, concrete facts on implementation issues are not available. This discussion is probably a little bit misleading. From the security perspective, Virtual Machines are an approach to realize Access Control on an Operating System level. This comes along with data isolation. Sandboxing is another option but on a higher layer in the application stack. Sure, security is not the main objective when applying solutions based on Virtual Machines. But these objectives, like flexibility and mobility, are topics we should take in account when talking about security in the scope of Virtual Machines. Why is that? Traditional security mechanisms were developed to protect non-virtualized systems (or real hardware in a broader sense). But Virtual Machines (better: systems based on it) behave different. They are mobile and highly dynamic (people do copy, move, switch on, switch off, change ownership), and follow different life-cycle patterns. This is not good news for firewalls, existing policies, access control within the scope of the VM, as well as for forensic analysis. Beside the technical issues, processes are not ready to face these challenges in many cases. Security folks and administrators should be aware of this and must update their instruments (tools, policies).
Other areas of security are affected as well. Cryptography is just one example. I’m gonna cover this fascinating topic in my upcoming posts. And, virtualization has started to exist in the clouds. How is security performing high above us in totally virtualized solutions? Mmmh.

BlackHat 2008 Revisited - this years location

Las Vegas, August 2008 - webduke pics

Web Browser, Web-OS and the Era of Clouds

The discussion about a “Web-OS” is alive and kicking. Some folks might call it Cloud Computing or Cloud*.*. However, new browser products and offline-gadget-frameworks are leading in this direction, and some blogs do emphasize this implicitly. Well, I don’t wanna spoil the party. Don’t get me wrong; I do not question the ideas of delivering software as a service or similar ideas. But my concerns about the underlying technologies like HTTP, HTML, JavaScript, AJAX and others still exist. Even simple applications (in comparison with a Web-OS) in the Web 2.0 environment are prone to security flaws. New threats pop up on a daily basis. Many web applications (> 90 percent) are vulnerable according to serious studies. Mail programs, automatic update services, browser plug-ins, communication services, all this stuff is affected. The Black-Hat 2008 sessions provide a decent overview on what is going wrong. Is this the right foundation to build a “Web-OS” based on? Not sure. In addition a “Web-OS” would increase our dependencies on the availability of the Internet; beside VOIP, television, mainstream Internet-Services and all the other stuff running over IP-Networks. On the other hand, today’s mainstream operating systems are making progress in terms of security, which is good news. Talking about client computing, I remember the times when a company came up with sleek, thin terminals (in blue color), and announced the end of the personal computer. Nothing really happened. Big fat machines (from different vendors running different big fat operating systems) still exist. And this is okay with me (as long as the multi-core issues will be solved). I do prefer a perfect symbiotic solution comprising a powerful and efficient machine and a fast web access with a lot of cool apps running in the clouds. And, I want to process my texts, spreadsheets and other documents locally. All of this should be working in a secure manner. And at the end of the day (when security concerns and paranoia prevail ;-)), I want to unplug the network cable without loosing the capability to work and to access my documents.

Wrapping-Up Black Hat

There have been a couple of highlights presented @Black Hat USA this year. I don’t want to distract interested folks from reading the docs and presentations which will be available from the website. Just some big topics from my point of view:

- DNS issues, DNS issues, DNS issues
- Web 2.0 (and also “Web-OS”) security problems
- Flaws in Software-update mechanisms via the internet
- Issues resulting in weak number generation