Security Primer

Introduction

Security is about managing risk. No usable system is 100% secure – that’s a fact. Of course it is possible achieve 100% security by placing a system in a physically guarded bank vault and disabling all communication mechanisms. Based on how the society uses software systems it's clear that such approach is not suitable for most usable software systems. It’s not possible to defend against all vulnerabilities, not only because organizations don’t have the resources, but because new threats arise daily. It’s the architect’s job to work with the system stakeholders to seek the balance between risks and resources.

This article is for both seasoned and apprentice software architects. Security has always been an important topic, but with rapid software evolution software architects are forced to pay more attention to this quality attribute. In not so distant past, before standardization of various protocols (e.g. TCP/IP, SMTP, etc.) most business systems were isolated and existed within the physical boundaries of proprietary communication infrastructure. At that time there was little, if any, electronic data exchange between organizations. The subject of security did not become prevalent until the need for interconnectivity and interoperability emerged and the cost of security breach became a real cost to a business.

Key Terminology

Threat — A potential event that could lead to a system compromise. E.g. submitting an ill-formed XML document to a web service or a SQL injection.

Attack — A realization (instance) of a threat. E.g. Unauthorized user trying to break into a system for the purpose of stealing customer information.

Vulnerability — A flaw or defect, if exploited, could result in a security compromise. A flaw can be in system security policy, code, design, or installation. E.g. role A, if renamed, is allowed to perform role B’s actions even though it’s not supposed to.

Security procedure – A set of steps a user or a process must perform in order to get access to a system resource. E.g. a user’s password must include letters and special characters.

Security technologies – Software or hardware that allows you to implement security policies. These are the building blocks that must be set in order to be effective. E.g. firewalls, SSL, auditing software.

Authentication – The process of establishing the validity of a claimed identity. E.g. user name & password or a retinal scan. This topic becomes complex in the systems where a system user will never physically appear in front of the system registrant (e.g. security office in a company).

Authorization – The process of determining whether an authenticated entity is allowed access to a secured asset. This process is complex to establish and troublesome to test, because various degrees of authorization are possible. A set of rules must be established and type of access control control (mandatory vs. discretionary) must be determined.

Accountability – The ability to associate and identify a user or an entity with their interaction of a secure asset. Accountability is can be implemented through auditing. This is a difficult issue to successfully implement, but more importantly to determine what secure assets should be monitored to determine who accessed, when, and what did they do to that asset, was it authorized, and what is the damage. The topic of security addresses the following key goals:

Confidentiality – Preventing disclosure of of information to unauthorized users, entities, or processes. E.g. accidental disclosure of credit card information. Once information is disclosed it's impossible to get it back.

Integrity – Preventing modification or destruction of an entity by an unauthorized user, entity, or a process. E.g. guaranteeing that the content of an email message sent by a sender was not modified in transit.

Availability – Thwarting the threats that might impact the ability of users to access it. E.g. denial-of-service attacks on Amazon.com where the company shall loose money for every minute that users can't place orders.

Non-repudiation – Preventing any participant (user, process, or a subsystem) from denying it's role in an interaction. E.g. electronic signature for email.

The Known Unknowns

When working with a business stakeholder (e.g. system owner, customer, management, etc.) it's important to explain the known unknowns.

Quality Attributes & Tradeoffs

Security is a tactic that promotes availability, robustness, and audit quality attributes. It has a neutral effect on promotion of usability, adaptability, or evolution. And the security tactic conflicts with performance, scalability, interoperability, maintainability, and portability quality attributes.
Examples for conflicting quality attributes:

SEI Recommendations

The security professionals at the Software Engineering Institute (SEI) have established the following best practices.
Security is integral to system architecture. It has to be part of the software engineering process. Ad-hoc design elements will break architecture if you try to retrofit security later on.
Defense-in-depth. Always have more than one technology procedure for defense. E.g. multiple vendors for firewalls.
Establish zones of trust.
Least Privilege. At start nobody can do anything. Then give rights as necessary. E.g. install firewall and then open ports as necessary. Need to establish a reason or need that you have a need for access. Every resource is denied, unless explicitly given.
Simplicity. The more complex something the more likely users will try to avoid it. E.g. auto generated passwords are too complex to manage. If user doesn’t like it they will find a way around (e.g. by writing down a password on a piece of paper and keeping it on a desk).
Balance risk with cost. If security costs more than the data you’re trying to protect it’s not worth the cost. What’s the opportunity cost? What are the tradeoffs among alternatives. Need to balance risk. Every system has a different tolerance level. Every company has a different tolerance for risk.
Protect information in transit and in storage. If you transmit the data in the clear and someone is listening there’s loss. It may or may not be important to protect. Will that information be transmitted. Many passwords are stored secure, but transmitted clear or with weak encryption mechanisms.
Never believe you're totally secure.
Deciding on the Level of Expertize Required
Security architecting has become a specialized area of software & system architecture. This segment of the software architecture discipline is getting attention and now with recent multimillion dollar losses at American clothing retailers - respect. Many organizations don't have a designated specialist responsible solely for designing security into a software system. It's often expected that software engineers will take care of it. Further, this segment of design is often subcontracted, because making appropriate decisions requires familiarity with technologies, vulnerabilities, protocols, etc. A good architect needs to be able to understand the business problem and intellectual assets of his team to decide the level of external support necessary to help him or her design the system properly.

Conclusion

This article introduced the core concepts of security with respect to the software architectures domain. Security is about understanding the level of risk a system and an organization is willing to take with respect to cost. Security is about managing risk and making conscious tradeoffs between other quality attributes.


2013 © SoftwareArchitectures.com | Privacy Policy | Terms of Service