secure by design - why design matters

src: Secure by Design by Dan Bergh Johnsson | Goodreads

Abstract

• It’s better to view security as a concern to be met than to view it as a set of features to implement.
• It’s impractical to achieve security by keeping it at the top of your mind all the time while developing. A better way is to find design practices that guide you to more secure solutions.
• Any activity involving active decision-making should be considered part of the software design process and can thus be referred to as design.
• Design is the guiding principle for how a system is built and is applicable on all levels, from code to architecture.
• The traditional approach to software security struggles because it relies on the developer to explicitly think about security vulnerabilities while at the same time trying to focus on implementing business functionality. It requires every developer to be a security expert and assumes that the person writing the code can think of every potential vulnerability that can occur now or in the future.
• By shifting the focus to design, you’re able to achieve a high degree of software security without the need to constantly and explicitly think about security.
• A strong design focus lets you create code that’s more secure compared to the traditional approach to software security.
• Every XML parser is implicitly vulnerable to entity attacks because entities are part of the XML language.
• Using generic types to represent specific data is a potential door opener for security weaknesses.
• Choosing the XML parser configuration is difficult without understanding the underlying parser implementation.
• Secure by design promotes security in-depth by adding several layers of security.

Security is a concern, not a feature. The difference is that even when security features address a specific security problem, your concern about security may not have been met.

By shifting the focus to design, you’ll be able to achieve a high degree of software security without the need to constantly and explicitly think about security.

• design is a natural part of the software development
• business concerns and security concerns become of equal priority
• domain focus solves security bugs implicitly

The caveat with the notion of adding security later is that it might not be possible if the security aspects needed imply a fundamentally different design. This is similar to why it’s usually hard or impossible to add scalability or statelessness late in the software cycle.

Categorizing security concerns: CIA-T

• Confidentiality: Most often associated with talking about security, is about keep- ing things secret that shouldn’t be made known to the public. Your healthcare record is one of the best examples of confidential information.
• Integrity: Refers to when it’s important that the information doesn’t change or is only allowed to change in specific, authorized ways. An example of integrity is counting election results. Security in this context means that the votes haven’t been manipulated.
• Availability: Means data is at hand in a timely manner. The fire department needs to know about the location of a fire, and they need that information immediately. If they get the location later, it might be too late, and the need for security can’t be met.
• Traceability: captures the need for knowing who changed or accessed what data when.

Dealing with strings, XML, and a billion laughs

• apply a design mindset: treat as input validation problem
  • e.g. for XML, add configuration to ensure only what elements are required, and remove the other elements
  • downside: only works when entities are illegal
• apply operational constraints
  • e.g. size too big ⇒ memory footprint too dangerous
  • parsing done in isolation

Metaphor:

• configuring parser ⇒ build a strong fence around the house
• lexical scan to make sure only required elements are passed to the parser ⇒ only let people with keys into the house
• operational constraint, lexical scan and pass entities to the parser, similar to having a window open on the second floor ⇒ watchdog inside the house

Deep modeling

Shallow modeling leads to implicit concepts, which are dangerous as they can lead to high risk of buggy and insecure code.

Shallow modeling often emerges when representing the models with primitives, like integers, strings and so forth (which is also called “primitive obsession”).

One way to mitigate is to make the implicit explicit by taking a few minutes to discuss a little bit more deeply (spell it out as part of the design). This leads to create more classes to represents the business models, which may put a brake for some, but all the interesting business rules have to be caught in code, or else you’re creating a worse system.

• Incomplete, missing, or shallow modeling leads to a design with security flaws.
• A security flaw in the form of broken business integrity can live in production for long time, bleeding money from your enterprise.
• Conscious, explicit design results in a much more robust solution.