STRIDE – Adventures in the programming jungle

(My) CSSLP Notes – Secure Software Design

1 August, 201719 May, 2017Adrian Citu

Note: This notes were strongly inspired by the following books: CSSLP Certification All in one and Official (ISC)2 Guide to the CSSLP CBK, Second Edition

Design Process

Attack Surface Evaluation

A software or application’s attack surface is the measure of its exposure of

being exploited by a threat agent i.e., weaknesses in its entry and exit points that a malicious attacker can exploit to his or her advantage.

The attack surface evaluation attempts to enumerate the list of features that

an attacker will try to exploit.

Threat Modeling

Threat modeling is the process used to identify and document all the threats to system.

The threat modeling process have 3 phases:

model the system for which you want to find the threats.
find the threats.
1. STRIDE model.
2. attack trees – An attack tree is a hierarchical tree-like structure, which has either an attacker’s objective (e.g., gain administrative level privilege, determine application makeup and configuration, bypass authentication mechanisms, etc.) or a type of attack
  (e.g., buffer overflow, cross site scripting, etc.) at its root node.
address each threat found in the previous step. Once identified,each threat must be evaluated according to the risk attached to it. There are several ways to quantitatively or qualitatively determine the risk ranking for a threat. These range from the simple, non-scientific, Delphi heuristic methodology to more statistically sound risk ranking using the probability of impact and the business impact.
document and validate.

More details about threat modeling can be found here : Threat Modeling for mere mortals and (My) OWASP BeNeLux Days 2016 Notes – Training Day.

Design Considerations

This part is linked to the Secure Software Concepts and contains how the security software concepts can be applied to have a secured application.

confidentiality – use cryptographic and masking techniques
integrity – use hashing (or hash functions), referential integrity design (uses primary keys and related foreign keys in the database to assure data integrity), resource locking (when two concurrent operations are not allowed on the same object (say a record in the database), because one of the operations locks that record from allowing any changes to it, until it completes its operation, it is referred to as resource locking), and code signing.
availability – replication, fail-over and scalability techniques can be used to design the software for availability.
authentication – use multi-factor authentication and single sign on (SSO). Rely of already existing mechanism if possible (like the ones offered by the operating system).
authorization – rely of already existing mechanism if possible.
accounting (audit) – determine of what elements should be logged and under what circumstances.

Some of the common, insecure design issues observed in software are the

following:

improper implementation of least privilege
software fails insecurely
authentication mechanisms are easily bypassed
security through obscurity
improper error handling
weak input validation

Architecture system with secured design principles:

good enough security – care should be taken to ensure that the security elements are in response with the actual risk associated with the potential vulnerability; do not over-engineer.
least privilege – use of accounts with non-administrative abilities.
Modular programming is a software design technique in which the entire program is broken down into smaller sub-units or modules. Each module is discrete with unitary functionality and is said to be therefore cohesive, meaning each module is designed to perform one and only one logical operation.
separation of duties – the programmer should not be allowed to review his own code nor should a programmer have access to deploy code to the production environment.
defense in depth
- use of input validation along with prepared statements or stored
  
  procedures, disallowing dynamic query constructions using user
  
  input to defend against injection attacks.
- disallowing active scripting in conjunction with output encoding
  
  and input- or request-validation to defend against Cross-Site
  
  Scripting (XSS).
fail safe
- the user is denied access by default and the account is locked out after the maximum number (clipping level) of access attempts is tried.
- errors and exceptions are explicitly handled and the error messages are non-verbose in nature.
- not designing the software to ignore the error and resume next
  
  operation
economy of mechanism – trade-off that happens between the
usability of the software and the security features that need to be designed and built in.
- Unnecessary functionality or unneeded security mechanisms should be avoided.
- Strive for simplicity.
- Strive for operational ease of use.
complete mediation –
open design – the inverse of the open design principle is security through obscurity, which means that the software employs protection mechanisms whose strength is dependent on the obscurity of the design.
least common mechanism – mechanisms common to more than one user or process are designed not to be shared. Design should compartmentalize or isolate the code (functions) by user roles, since this increases the security of the software by limiting the exposure.
psychological acceptance – security principle that states that security mechanisms should be designed to maximize usage, adoption, and automatic application.The security protection mechanisms:
- are easy to use,
- do not affect accessibility.
- are transparent to the user.
weakest link – when designing software, careful attention must be
given so that there are no exploitable components.
leverage existing components – reusing tested and proven, existing libraries and common components has good security benefits.

Securing commonly used architectures

mainframe architecture
distributed architecture
- client/server
- p2p
service oriented architecture
- An ESB is a software architectural pattern that facilitates communication between mutually interacting software application.
- web-services
  - SOAP
  - REST
rich internet aplications (RIA)

Service models:

Infrastructure as a Service (IaaS) -infrastructural components such as networking equipment, storage, servers and virtual machines are provided as services and managed by the cloud service provider.
Platform as a Service (PaaS) -in addition to infrastructural components, platform components such as operating systems, middleware and runtime are also provided as services and managed by the cloud service provider.
Software as a Service (SaaS) – in addition to infrastructural and platform components, data hosting and software applications are provided as services and managed by the cloud service provider.

Digital Rights Management

The expression of rights is made possible by formal language, known as Rights Expression Language (REL). Some examples of REL include the following:

Open Digital Rights Language (ODRL) – A generalized, open standard under development that expresses rights using XML.
eXtensible rights Markup Language (XrML) – Another generalized REL that is more abstract than ODRL. XrML is more of a meta-language that can be used for developing other RELs.
Publishing Requirements for Industry Standard Metadata

(PRISM) – Unlike ODRL and XrML, PRISM can be used to express

rights specific to a task and is used for syndication of print media

content such as newspapers and magazine.

Trusted computing:

Trusted Platform Module (TPM) – specification used in personal computers and other systems to ensure protection against disclosure of sensitive or private information as well as the implementation of the specification itself.
Trusted Computing Base (TCB) – the set of all hardware, firmware and software components that are critical to its security.

(My) OWASP BeNeLux Days 2016 Notes – Conference Day

21 March, 201621 March, 2016Adrian Citu

Here are my quick notes from the OWASP BeNeLux Days 2016 conference day. All the slides can be found on this page.

Gamers, You’re the new Botnets

This presentation was about how to educate the teenagers to be aware of the dangers installing cracked video games.

The first part of the presentation was an practical example of what a system containing cracked video games is doing in background:the system was connected to external IP addresses from different countries, various ports were open to the target machine, even an cloud hard drive data backup software it was silently operating.

The second part of the presentation was about a process that could be applied in order to reduce the risk of transforming the pc in a botnet client. This process implied:

the use of an intermediary pc on which a scan of the downloaded games could be done.
a virtual machine on which the Wireshark is installed. On this VM, the game could be eventually installed.

Top 10 privacy risks in web applications

The goal of this presentation was to present the OWASP Top 10 Privacy Risks Project which have as goal to identify the most important technical and organizational privacy risks for web applications and to propose some mitigations techniques.

The top 10 privacy risks:

Web Application Vulnerabilities
Operator-sided Data Leakage
Insufficient Data Breach Response
Insufficient Deletion of personal data
Non-transparent Policies, Terms and Conditions
Collection of data not required for the primary purpose
Sharing of data with third party
Outdated personal data
Missing or Insufficient Session Expiration
Insecure Data Transfer

LangSec meets State Machines

For me this presentation contained two separate and independent tracks.

The first track was around LANGSEC: Language-theoretic Security The LangSec idea (which sounds very appealing) is to treat all inputs of an applcation (valid or invalid) as a formal language. In this case then the input validation would be done using a a recognizer for that language.

LangSec principle: no more handwriter parsers but:

precisely defined input languages
generated parsers
complete parsing before processing
keep the input language simple & clear

The second track was around the use of state diagrams in order to detect security flows in different protocols (GSM, SSH). Lot of protocols have states and it is possible to compute the state machine of a protocol using a black box testing approach.

The Tales of a Bug Bounty Hunter

The author is participating to the Facebook Bug Bounty Program and the presentation was about the different security vulnerabilities found in the Instagram application. For each vulnerability, a detailed description was made.

The most surprising fact was that the impact of the vulnerabilities found was not at all linked to the time/effort spent to find the vulnerabilities :).

OWASP Secure Knowledge Framework (SKF)

The OWASP SKF is intended to be a tool that is used as a guide for building and verifying secure software.

The 4 Core usage of SKF:

Security Requirements using OWASP Application Security Verification Standard (ASVS) for development and for third party vendor applications.
Security knowledge reference (Code examples/ Knowledge Base items) in PHP and C# (not yet in Java)
Security as part of design with the pre-development functionality. The developer can choose the type of functionality taht he wants to implement and SKF will make a reports with all the security hints/infos that he should be aware.
Security post-development functionality for verification with the OWASP ASVS

The application is an web application and can be runned on local systems of developers or on a server.

Challenges in Android Malware Detection

A traditional way of malware detection:

collect suspicious samples
analyze the samples (usually manually)
extract the signature

A smarter solution could be that given a set of known malwares + known goodwares + use data mining techniques to detect unknown samples.

The main problem of this approach is that :

there are a few small sets of known malwares
there are no set of known goodwares

The conclusion is that is very difficult to build the wright set of malwares and goodwares so there is not possible to have an automatic malware detection process.

Serial Killer: Silently Pwning your Java Endpoints

This presentation is about the Java deserialization vulnerability. Tha authors explains how the vulnerability works, what products/frameworks are affected and also what are the possible mitigations. The best mitigations is to not use at all the serialization/deserialization process and/or replace it by JSON or XML.

The slides of this presentation can be found here.

Threat Modeling for mere mortals

18 January, 20167 January, 2016Adrian Citu

This ticket is an introduction to the threat modeling in the context of software development.

Definition

In the context of the IT security, threat modeling is a structured approach that enables you to identify, quantify, and (eventually) address the security risks associated with an application.

A more formal definition

For somebody having the security mindset the previous definition might be not very formal; let’s try a new definition but before let’s introduce some new definitions:

asset – an asset is what it must be protected. In the context of software, it could be the infrastructure, the software installed, the user data.
vulnerability – a vulnerability is a weakness that can be present in one of the assets.
threat – anything that can exploit a vulnerability and obtain, damage, or destroy an asset.
risk – the potential for loss, damage or destruction of an asset as a result of a threat exploiting a vulnerability.

So, the threat modeling (also sometimes called risk analysis or architectural risk analysis) is the process integrated in the SDLC (Software Development Life Cycle) having as goal to find and address (mitigate, eliminate, transfer or accept) all possible risks for a specific software functionality.

The threat modeling should be applied in the SDLC as early as possible, ideally in the requirements phase (the earliest the problems will be found the easiest would be to fix) and could even modify or adjust the requirements.

The threat modeling process

The threat modeling process have 3 phases:

model the system for which you want to find the threats.
find the threats.
address each threat found in the previous step.

1. Model the system

The goal is to have a diagram representing the system under process. In the specialized literature, the Data Flow Diagrams are very often used because it easily represent all interaction points that an adversary can leverage to attack a system and also show how data moves through the system. The diagram could be improved adding “trust boundaries”, boundaries where data changes its level of “trust”.

2. Find the threats

After having a diagram of the system then you can ask how an attacher could attack the system. There are different approached that can be used to find “what can go wrong”:

STRIDE –this methodology (created by Microsoft) classifies threats into 6 groups:Spoofing, Tampering, Repudiation,

Information Disclosure, Denial of Service and Elevation of Privilege.

Threat Modeling is executed by looking at each component of the system and determines if any threats that fall into these categories exist for that component and its relationships to the rest of the system.
Threat/Attack libraries – libraries containing common and already known attacks. Threat library can be a quick way to take advantage of industry security knowledge (helping teams that lack sufficient knowledge themselves). Some examples of Threat libraries: OWASP Top Ten, CAPEC, CWE.
Misuse cases – These cases should be derived from the requirements of the system, and illustrate ways in which protective measures could be bypassed, or areas where there are none.

3. Addressing the threats

Once identified,each threat must be evaluated according to the risk attached to it (using a risk rating system such as Common Vulnerability Scoring System), the resources available,the business case and the system requirements.

This will help prioritize the order in which threats should be addressed during development, as well as the costs involved in the mitigation (if you decide to mitigate it).

Not all the treats can be mitigated. It is also possible to decide that some of them should be eliminated (meaning that the feature of the functionality that if affected should be removed), transfered (let somebody or something else to handle the risk) or accepted (accept the risk that could happen).