Saturday, October 31, 2009

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.

Saturday, October 24, 2009

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.

Friday, October 23, 2009

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