Security Design Principles �and Patterns

Dr. Mohammad Shoab

Security Design Principles

• Security Design Principles have been created to help developers build highly secure applications.

​

Asset Clarification

• Before developing any security strategies, it is essential to identify and classify the data that the application will handle.
• Programmers create security controls that are appropriate for the value of the data being managed.
• For example, an application processing financial information must have much tighter restrictions than a blog or web forum.

​

Understanding Attackers

• Programmers should design controls that prevent misuse of the application by different types of malicious parties, including (from most to least dangerous):
• Dissatisfied staff members and programmers
• Drive-by attacks that release viruses or Trojan attacks onto the system
• Motivated cybercriminals (with the intention of stealing sensitive company information or personal data, and generating profit)
• Criminal organizations with malicious intent
• Script kiddies

​

Core Pillars of Information Security

• Security controls should be designed with the core pillars of information security in mind:
• Confidentiality – only allow access to data for which the user is permitted
• Integrity – ensure data is not tampered or altered by unauthorized users
• Availability – ensure systems and data are available to authorized users when they need it

​

Security Architecture

• Every application has application security measures designed to cover all kinds of risks, ranging from typical usage risks (accidental data erasure) through to extreme attacks (brute force attacks, injection attacks etc.).
• It is recommended that developers should consider each feature on the application they are designing and ask the following questions:
• Is the process surrounding this feature as safe as possible? In other words, is this a flawed process?
• If I were evil, how would I abuse this feature?
• Is the feature required to be on by default? If so, are there limits or options that could help reduce the risk from this feature?

​

Security Design Principles

Security Design Principles

1. Minimise Attack Surface Area

• Every time a programmer adds a feature to their application, they are increasing the risk of a security vulnerability.

​

• The principle of minimizing attack surface area restricts the functions that users are allowed to access, to reduce potential vulnerabilities.

​

Defining the Attack Surface of an Application

The Attack Surface of an application is:

• the sum of all paths for data/commands into and out of the application, and
• the code that protects these paths (including resource connection and authentication, authorization, activity logging, data validation and encoding), and
• all valuable data used in the application, including secrets and keys, intellectual property, critical business data, personal data and PII, and
• the code that protects these data (including encryption and checksums, access auditing, and data integrity and operational security controls).

​

1. Minimise Attack Surface Area (contd.)

• For example, you might code a search feature into an application. That search feature is potentially vulnerable to file inclusion attacks and SQL injection attacks.

​

• The developer could limit access to the search function, so only registered users could use it — reducing the attack surface and the risk of a successful attack.

​

2. Establish Secure Defaults

• This principle states that the application must be secure by default.
• That means a new user must take steps to obtain higher privileges and remove additional security measures (if allowed).
• Establishing safe defaults means there should be strong security rules for:
• how user registrations are handled,
• how often passwords must be updated,
• how complex passwords should be and so on.
• Application users may be able to turn off some of these features, but they should be set to a high-security level by default.

2. Establish Secure Defaults (contd.)

3. Least Privilege Design Principle

• The Principle of Least Privilege (POLP) states that a user should have the minimum set of privileges required to perform a specific task.
• For example, a user who is signed up to a blog application as an “author”
• should not have administrative privileges that allow them to add or remove users.
• They should only be allowed to post articles to the application.
• The POLP can be applied to all aspects of a web application, including user rights and resource access.

​

4. The Principle of Defense in Depth

• The principle of defense in depth states that multiple security controls that approach risks in different ways is the best option for securing an application.
• So, instead of having one security control for user access, you would have multiple layers of validation, additional security auditing tools, and logging tools.
• For example, instead of letting a user login with just a username and password,
• you would use an IP check,
• a Captcha system,
• logging of their login attempts,
• brute force detection and so on.

What is CAPTCHA?

• This user identification procedure has received many criticisms, especially from people with disabilities,
• Also from other people who feel that their everyday work is slowed down by distorted words that are difficult to read. It takes the average person approximately 10 seconds to solve a typical CAPTCHA.

This CAPTCHA (Version 1) of "smwm" disguises its message from computer interpretation by twisting the letters and adding slight background color gradient.

5. Fail-Safe Defaults Design Principle

• There are many reasons why an application would fail to process a transaction.
• Perhaps a database connection failed, or the data inputted from a user was incorrect.
• This principle states that applications should fail in a secure way.
• Failure should not give the user additional privileges,
• It should not show the user sensitive information like database queries or logs.

5. Fail-Safe Defaults Design Principle (contd.)

6. Don’t Trust Services

• Many web applications use third-party services for accessing additional functionality or obtaining additional data.
• This principle states that you should never trust these services from a security perspective.
• That means the application should always check the validity of data that third-party services send and not give those services high-level permissions within the app.

7. Separation of Duties

• Separation of duty, as a security principle, has as its primary objective the prevention of fraud and errors.
• This objective is achieved by distributing the tasks and associated privileges for a specific business process among multiple users.
• For example, a user of an e-Commerce website should not be promoted to also be an administrator as they will be able to alter orders and give themselves products.
• The reverse is also true — an administrator should not have the ability to do things that customers do, like order items from the front end of the website.

7. Separation of Duties (contd.)

8. Avoid Security by Obscurity

• In security engineering, security through obscurity (or security by obscurity) is the reliance on the secrecy of the design or implementation as the main method of providing security for a system or component of a system.
• A system or component relying on obscurity may have theoretical or actual security vulnerabilities, but its owners or designers believe that if the flaws are not known, that will be sufficient to prevent a successful attack.
• Security experts have rejected this view, and advise that obscurity should never be the only security mechanism.
• If your application requires its administration URL to be hidden so it can remain secure, then it is not secure at all.
• There should be sufficient security controls in place to keep your application safe without hiding core functionality or source code.

Security by obscurity Example 1

• The key to the front door is stashed under a rock nearby, or under the welcome mat, or on top of a high railing.
• These are all instances of security through obscurity,
• it is right out in the open for anyone to grab,
• most people will not be able to find it without huge amounts of searching.
• However, a dedicated attacker can walk right in.

Security by obscurity Example 2

• Some people like to make their javascript difficult to read (and therefore hack) by using obfuscation.
• Google is among the users of this technique. At the simplest level, they change the variable and method names to a single mysterious letter. The first variable is named "a", the second is named "b" and so on.
• It does succeed in making the javascript exceedingly difficult to read and follow.
• And it adds some protection to the intellectual property contained in the javascript code, which must be downloaded to the user's browser to be usable, therefore making it accessible to all.

​

Security by obscurity Example 2 (contd.)

Disadvantages of Obfuscation

• While obfuscation can make reading, writing, and reverse-engineering a program difficult and time-consuming, it will not necessarily make it impossible.
• Some anti-virus software, such as AVG AntiVirus, will also alert their users when they land on a site with code that is manually obfuscated, as one of the purposes of obfuscation can be to hide malicious code.
• Certain major browsers such as Firefox and Chrome also disallow browser extensions containing obfuscated code.

​

Disadvantages of Obfuscation

• However, some developers may employ code obfuscation for the purpose of reducing file size or increasing security.
• The average user may not expect their antivirus software to provide alerts about an otherwise harmless piece of code, especially from trusted corporations, so such a feature may actually discourage users from using legitimate software.

​

9. Keep Security Simple

• Developers should avoid the use of very sophisticated architecture when developing security controls for their applications.
• Having mechanisms that are very complex can increase the risk of errors.
• In Practice:
• Reuse components that you know to be trusted.
• Avoid complex architecture and coding
• Centralize your approaches by making the fundamentals part of your design.
• Integrate your security tools within the developers already-familiar environments, including their IDE, build management, source repository, bug tracking system, etc.

​

10. Fix Security Issues Correctly

• If a security issue has been identified in an application developers should :
• determine the root cause of the problem
• Identify the pattern of the problem
• They should then repair it
• test the repairs thoroughly (regression tests)
• If the application uses design patterns, it is likely that the error may be present in multiple systems.
• Programmers should be careful to identify all affected systems.

Thanks!