Secure Software Design — Part 1

When developing applications and computer software, developers focus on writing and testing accurate software that meets the requirements of the user. The security aspect of software design requires the same attention and testing but is often overlooked in favour of faster time to deployment. This poses a huge risk to the system in the long run as attackers may exploit vulnerabilities to try to steal personal or corporate information, modify information by installing malware or deny access to the system affecting the C,I and A respectively. Currently, most organisations employ black-box techniques such as firewalls, intrusion detection systems and anti-virus scanners (explained below). However, these are not as effective if the software is flawed and full of security bugs, creating a need for software security. Software Security focuses on secure design and implementation of software from the coding level and is explained in the next post (TK: add link to part 2)

This is part of a series covering topics in Information Security:

1. Introduction to Information Security
2. Security in the Cloud
3. Challenges in Mobile Security
4. Secure Software Design — Part 1 (this post)
5. Secure Software Design — Part 2

Security in the Software Development Lifecycle

Security needs to be considered throughout the lifecycle to prevent, mitigate and detect possible attacks. Flaws caught early in the process cost a lot less to fix than later on!

1. Requirements: Defining security requirements and identifying abuse cases
2. Design: Carrying out rchitectural risk analysis (or threat modelling) and security-aware design
3. Implementation: Conduct code reviews, conduct static analysis and follow secure programming practices
4. Testing/Assurance: Carry out risk-based security and penetration testing

OWASP’s Security by Design Principles

• Minimize attack surface
  Enforce user authentication to access certain services (now only authenticated users can try to attack rather than just anybody)
• Establish secure defaults
  The default option should always be secure, and then have options for users to reduce security
• Principle of least privilege
  Each user/employee is given the least permissions required to complete their job and no more
• Defence in Depth
  Set up several layers of security, so that if an attacker gets through one, they are stopped by other layers
• Fail securely
  Use try-catch blocks strategically to ensure maximum security and give generic error messages to the user
• Don’t trust services
  3rd-party services should not be trusted and handled carefully
• Separation of duties
  Keep roles separate and avoid giving a single role too many functions
• Avoid security by obscurity
  Keeping a vulnerability secret should only be used along with other lines of defence since it nearly always fails and someone will attack it
• Keep security simple
  Use straightforward and simple approaches when possible
• Fix security issues correctly
  Identify the root cause, develop a test and fix the issue. Ensure regressions (a change in one part of the code causes other parts of the system to fail) are not introduced when fixing the bug, especially when dealing with shared functions.

Read more about it here.

Black-box Defences

Operating system security

Operating systems provide a layer of security by governing a program’s actions by enforcing file access permissions (based on users and groups in Linux), controlling ports, sending and receiving network packets, starting programs with specific permissions and in namespaces (filesystem, network etc). Filesystem namespaces, for example, provide isolation from the rest of the system since a process running in a namespace cannot access files/directories outside that namespace.
However, an operating system cannot enforce fine-grained, application-specific policies and may reveal something indirectly to an attacker through its information flow.

Firewalls

Firewalls can intercept and monitor traffic through the ports and block suspicious payloads based on the content and origin of the traffic.
However, firewall filtering is usually coarse-grained and may not be able to adapt if, for example, previously benign ports become malicious (due to malware already in the system).

Intrusion Detection Systems (IDS)

An IDS can filter and block packets if its part of a known exploit pattern and alert the user.
On the downside, the IDS filter merely looks for syntactic similarities (not semantic) and can be bypassed if the attack traffic is modified to work around the filter. An IDS may also affect the availability of the service since its fine-grained filtering causes a drop in performance.

Anti-virus scanners

These look for malicious behaviour in a system’s files and known malware patterns. Similar to an IDS, they can be bypassed by modifying the malware and face the performance vs precision trade-off.

Examples of exploited vulnerabilities

RSA breach in 2011

The malicious Flash program was embedded into an Excel spreadsheet and ran automatically when the spreadsheet opened. The carefully crafted code ran on a vulnerable version of Adobe Flash Player which allowed arbitrary malicious code to be executed on the machine. The spreadsheet was propagated through spear phishing — attached to an e-mail appearing to be from a trusted party.

Heartbleed in 2014

This bug was found in the OpenSSL implementation of the SSL/TLS network protocol in 2014 (note: the vulnerability had been present in released code since 2012). A carefully crafted code causes OpenSSL to return parts of a server’s memory — a large number of attempts over time could collect usernames/passwords and other sensitive information.

Note: This post has been made with reference to slides used in Information Security lectures by Mr Prasad Honnavalli and various online sources