Agile Application Secuirty Framework

Agile Application Secuirty Framework

Agile Applica*on Security Framework Enhyper Ltd

Table of Contents

1


Introduc*on The Agile Applica,on Security Framework is data lifecycle focussed and lightweight in that there is considerable op,onality. It has a single interface: a checklist which serves as documenta,on for the data flows of the applica,on or component that is mandated as part of the sprint/epic. The checklist is documented using the principles of Usable Security¹⁰ i.e. it is well annotated so the user can understand the concepts of data security and privacy, the protec,on mechanisms provided by the infrastructure and those which must be created during the development lifecycle. This offers security improvements at low cost, allows nonexperts to understand the applica,on and it's threat environment and is easy to iterate. Threat modelling is presented in the context of the applica,on domain and details both generic and specific threats. Adherence to the above methodology does not remove the need to perform a comprehensive penetra,on test prior to produc,on roll out but it raises the awareness of security and privacy whilst capturing real-world threats which can guide the focus of the penetra,on test. The target audience are assumed to be competent developers who are fully conversant with the features and development piKalls of their chosen implementa,on language therefore this document does not cover standard programming prac,ces and language features.

Background Informa,on Security is tradi,onally the domain of network engineering teams. With internet connec,vity, there became a need for applica,ons to mi,gate vulnerabili,es such as buffer overflows. This became a formal role of Security "Domain Experts" advising developers and architects on how to design secure solu,ons using infrastructure and middleware. Unfortunately, network engineers who became security experts lacked applica,on development experience and had liPle influence with the developer community leading to risk assessment becoming a post-implementa,on exercise that delivered liPle value. It was also a costly and subjec,ve process (con,ngent on the exper,se of the domain expert) so it was ra,onalised to a series of standards driven by internal/external audit which led to a process which delivered liPle in the way of prac,cal security. In parallel with this, penetra,on tes,ng was maturing and becoming a tool-driven process rather than a black art. However, this too was highly specialised work, of subjec,ve quality and delivered a high degree of "false posi,ves" which were difficult to diagnose. Remedia,ng the true posi,ves was also post implementa,on and expensive in both resource and ,me to fix so business owners were reluctant to test their applica,ons. This situa,on has prevailed for several years and is now changing due to two factors: threat actors and increasingly sophis,cated automated exploit tools. Security is one again on the agenda. In the interim, some alterna,ve approaches were tried, such as threat modelling[⁷], sta,c code analysis using standard security development paPerns. Two of the world's largest organisa,ons in par,cular pioneered security threat modelling: Microso\ via the work of Adam Shostack and the European Union with their Shields Project ⁸. Both

2

Agile Application Secuirty Framework approaches were laudable in their intent but if their success is measured in the availability, usage and developer exper,se of func,onal threat models, both can be considered failures. The same can be said of Security Architecture PaPerns⁹ which took considerable effort but suffered two problems: distance from the applica,on developers and mission creep - too many irrelevant paPerns. In order to succeed, Informa,on Security needs provide something of u,lity to the applica,on development community, enhancing their delivery capability from project ini,a,on to, in Agile terms, 'Done'.

3


Document Structure There’s a quick start guide in the Appendix where you can find the Agile Security Task The document is organised thus: 1. Secure Software Development Lifecycle (SSDL): A quick overview of the SCRUM/AGILE methodology, defining the roles and where the methodology is augmented by the Agile Security Task. 2. Agile Application Security Methodology: This is a data centric capture, analysis and threat model for the Agile sprint/epic deliverable. This is added to the storyboard in the sprint or epic phase of the SCRUM lifecycle which is signed off by the product owner. 3. Threat Modelling: A brief discussion on threat modelling from the attackers perspective. 4. Mitigation Patterns: Mitigation provided by the infrastructure and software techniques and design patterns that can be used. 5. Agile Application Security Task: The Agile task in detail. This is available as a word document or a Confluence Template. I

4


The SCRUM Methodology

An Overview of the SCRUM Methodology A history of Agile development methodologies can be found in¹. Applica,on developers have adopted the Agile/SCRUM process as a way of coordina,ng the delivery of so\ware to the end-user. It has gained wide acceptance due to the inclusion of Agile extensions in the ubiquitous web-based toolset from Atlassian called JIRA Agile.

SCRUM Roles The key benefits of SCRUM is that the developers get to chose what to deliver in the next "sprint" and the user of the system gets what they ask for. The three principal roles are: Team Member: •

experts in the tools, architecture and techniques required to deliver the system.

Scrum Master: • • • •

scrum process expert coach impediment bulldozer facilitator

Product Owner: • • • • •

Holds the product vision Represents the business Owns and priori,ses the product backlog Creates acceptance criteria for items Available to team members to answer ques,ons.

Applying SCRUM to Informa*on Security Agile/Scrum is not about security per se but the delivery of systems which implicitly need to be secure otherwise they put the business at risk. The product owner is responsible for the informa,on security aspects of the system and it is the scrum master who is responsible for ensuring that Informa,on Security task is on the task board at the appropriate stage.

5

Agile Application Secuirty Framework This task comprises a checklist which details the data flows, their persistence, transforma,ons and synthesis during the lifecycle of the process. The security checklist integrated into the SCRUM framework means that the applica,on and its data is understood at an early stage in development. As it is a mandatory task, it cannot be put on the backlog.

6


Agile Application Security Methodology

Overview The Agile Applica,on Security Methodology has the following steps: •

Architectural Model: pictorial representa,on of the architecture together with a descrip,on of the high level components and how they interact

•

Data Analysis: list of data sources, sinks and synthesised data together with applica,on configura,on files. Detailed full-lifecycle analysis of each data feed covering physical, opera,on and security elements such as access control, transport, persistence.

•

Threat Modelling: Analysis of threats that apply to the components of the system together with a STRIDE analysis

This exercise is completed for each sprint/epic and is updated as the whole system progresses. An aggregate security analysis can be conducted for the system as a whole from each component. The end result is an accurate representa,on of the data artefacts and the security aspects of the system which can be used to run automa,c and directed penetra,on tests on the system with focussed coverage.

Architecture Modelling Tools: Below is a list of tools which are useful for diagramming architectures: YEd. hPp://www.yworks.com/en/products/yfiles/yed/ 7

Agile Application Secuirty Framework A simple tool wriPen in Java which is reliable, robust and scalable. It can produce UML diagrams which is ideal for threat modelling.

Methodology: In addi,on to the diagram, the architecture should be described in words, detailing each component and its func,on. The detail will be captured as part of the checklist task.

8


Data Analysis Overview Data is the vector for many application threats. The majority of data is transported via the network but there are other sources such as backup tapes, keyboards, usb drives etc. Documenting these sources as used by an application allows us to construct threat scenarios in the application context and where appropriate, mitigate those threats. We use a simple quad chart approach with axes of impact (low to high) and likelihood (again low to high) seeking to address the high impact and likelihood threats as a priority. Our approach to get use the SCRUM process to collect the data flows via the check list which will allow security domain experts to analyse the elements of the data flows which are necessary to provide a secure service with an acceptable service level. Deviation from this SLA and issues with security are notified to the central log analysis tool Splunk, an appropriate response initiated and remediation managed. Rather than looking from a pure threat point of view, we ask the developer document the source IP, port number at the very least. This can, for example, be used to drive firewall rules for that application.

Data Sources The majority of application data will be from the network. There are subtle threats which can compromise application availability (see CIA) and Source Network

Description

Disk

Disk space and resources, memory, system processes Malware

USB

Data from network cards

Risk high high high

Mitigation Firewalls, application firewalls, data input libraries Active space monitoring and escalation Data Loss Prevention

Data Input Threats Threat Resource Exhaustion Platform malfunction

Description Disk space and resources, memory, system processes Hardware Errors, power failures

9

Mitigation Active space monitoring and escalation Error detection and recovery

Agile Application Secuirty Framework Service Failure Data Tampering

Facility dependency failure Corruption of data

Retry and Escalation

hashing, cyclic redundancy checks

Synthesised Data Data that is created by the application from incoming data. For example a transaction summary report on a per client basis. Elevation of Security Level One of the chief concerns is that the aggregation of data causes an increase in information sensitivity. Appropriate measures must be taken to protect or prevent this. Data Synthesis Threats Threat Elevation in secrecy Conflation/ Integrity Disclosure

Description Disk space and resources, memory, system processes Loss of information Reveal data to unauthorised parties

Mitigation Active space monitoring and escalation Retention of original copy, metadata Encryption

Data Sinks Data that is supplied to downstream systems. Threat Interception Consumption Failure Service Failure Data Tampering

Description Disk space and resources, memory, system processes Failure for a downstream system to consume the data resulting in retention and downstream inaccuracies Failure of dependent service Data corruption

Application Configuration 10

Mitigation Active space monitoring and escalation process Escalation Process

Escalation, notification Hashing, cyclic redundancy checks, sequence checking

Agile Application Secuirty Framework Application configuration data is usually found in static files in a variety of formats. It is a significant source of application errors and fraud. Formats such as XML and comma separated values are complex formats for humans to edit and maintain. Some configuration can be refreshed during program operation, others require a restart of the program. Adequate protection of the file needs to be in place to ensure that the contents are not maliciously altered. Best practice is to have Configuration as a Service (CaaS) in which valid configuration is only supplied to an authenticated application on demand. This ensures the correct configuration is delivered.

Local Disk and System Memory This is the first persistence mechanism used by applications for a variety of purposes. The analysis of security requirements needs to address the level of protection required by this information in light of the value of the information and consequences of a breach.

Network This is the most common source and sink of data and can arrive over multiple network connections.

11


Threat Modelling

An Overview of Threat Modelling To identify the security requirements of software systems, many techniques have been developed over the years, however, we are still in the situation where security is an afterthought to the development process so it would appear that many of these have been quietly dropped (e.g. DREAD which has been discontinued by Microsoft.) There are four main reasons for their failure: • • • •

Additional Task: They don’t help the development process - they are seen as an additional task Lack of Domain Knowledge: Focus on security terms and threats that are usually alien to developers Subjective: Quality and coverage based on individual experience and time allocated. Numerical: A numerical value does not measure security. A comprehensive approach from design to penetration testing is more effective.

The security focussed check list answers these four points thus: • •

• •

Assists Development: Captures architecture, data flows and configuration information to help document the product. Tasks that are expected of a professional software engineer. LEAN: Minimalist approach, focusses on the discovery and documentation of assets. Can be extended as required to be a comprehensive review. The balance of these activities is between the software engineer and the security domain expert. Delivery Focussed: Assists the developer by providing detailed documentation of the system increasing knowledge and understanding. Secure Patterns: Familiarises and educates developers in secure application development practises by highlighting coding techniques and infrastructure facilities (such as F5 Networks) together with operational practises (logging application transactions to determine SLA)

Threat Modelling and Enumeration Definition: Threat modelling is the enumeration of threats which in simple terms is creating a list of known and likely threats. Deliverable: A list of threats in the operational context of the target to the system, application or components together with their mitigation.

12

Agile Application Secuirty Framework Caveats: By its nature it is a subjective process which is limited in coverage therefore it must be backed by a penetration test which uses a variety of tools and techniques to give greater coverage than any human driven approach. In Practise: Threat modelling can be performed by security domain experts and shared with software engineers, performed collaboratively with both engineers and experts, or done by engineers without experts available. It is rare that the middle case is performed due to the distributed nature of development so, in practise, the first and last cases prevail. Value: The value of creating a well annotated task adhering to the principles of usable security, that involves building a threat model, gives the engineers a sense of ownership and an understanding of the security model.

STRIDE Categorisation schemes abound as discussed in the overview. STRIDE is useful in the identification of threats by classifying attacker goals such as: • • • • • •

Spoofing Tampering Repudiation Information Disclosure Denial of Service Elevation of Privilege

A threat list of generic threats organised in these categories with examples and the affected security controls is provided in the following table:

STRIDE Threat List Type

Spoofi ng

Security

Examples Threat action aimed to illegally access and use another user's credentials, such as username and password.

13

Control Authenticatio n

Agile Application Secuirty Framework Threat action aimed to maliciously change/modify persistent data, such as Tampe

persistent data in a database, and the

ring

alteration of data in transit between two

Integrity

computers over an open network, such as the Internet. Repud iation Inform ation disclos ure Denial of servic e Elevat ion of privile ge

Threat action aimed to perform illegal operations in a system that lacks the ability to trace the prohibited operations. Threat action to read a file that one was not granted access to, or to read data in transit.

NonRepudiation

Confidentialit y

Threat aimed to deny access to valid users, such as by making a web server

Availability

temporarily unavailable or unusable.

Threat aimed to gain privileged access to resources for gaining unauthorised access to information or to compromise a system.

Conclusion A task is added to the task board of a story/epic in order to capture the data flows, events, processes and threats associated with an application. The flows and their attributes are described in terms that

14

Agile Application Secuirty Framework are easily understood by application developers. Info When that task is added to the sprint/epic is decided by the SCRUM master and the Product Owner. The latter takes the responsibility that the application security task has been 'Done' before sign-off for production use. This task currently is a spreadsheet but will be integrated as a module into the Atlassian JIRA Agile product. It serves two purposes: firstly, helping application developers understand their data flows from an information security perspective and secondly, making the risk assessment process part of the design/development lifecycle. The next step is to integrate security development patterns into the process which will further enhance the security of developed systems.

15


References #

Description

1

Agile Software Development http://en.wikipedia.org/wiki/Agile_software_development A Precise and General Inter-component Data Flow Analysis Framework for Security Vetting of Android Apps http://www.ieee-security.org/TC/SP2014/posters/WEIFE.pdf

2

3

4 5 6 7 8 9 10

Informed Consent by Design http://hornbeam.cs.ucl.ac.uk/hcs/teaching/GA10/lec9extra/ ch24friedman.pdf A Brief Introduction to Usable Security http://www.cc.gatech.edu/~keith/pubs/ieee-intro-usablesecurity.pdf OWASP Application Security Architecture Cheat Sheet https://www.owasp.org/index.php/ Application_Security_Architecture_Cheat_Sheet CaaS - Configuration as a Service https://www.usenix.org/conference/ucms14/summit-program/ presentation/schottelius Experiences Threat Modelling at Microsoft http://www.homeport.org/~adam/modsec08/ShostackModSec08-Experiences-Threat-Modeling-At-Microsoft.pdf The EU Shields Project http://cordis.europa.eu/project/rcn/85431_en.html Security Architecture Patterns http://enhyper.com/content/OOSecurityPolicy.ppt Usable Security http://www.cc.gatech.edu/~keith/pubs/ieee-intro-usablesecurity.pdf

16


Definitions Term

Definition

Business data entry

Sets of individual data elements grouped around a concept meaningful to the business e.g. Traveler might be the Business Entity and their name, address, telephone number etc. would be the individual data elements. Cross-Site Request Forgery

CSRF DAO HTTPS STRIDE ORM XSS

Data Access Object. An interface that abstracts access to a database or persistence mechanism. HTTP over TLS Acronym for Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Elevation of Privilege. Used as part of the Microsoft approach to threat modelling. Object/Relational Mapper. A library that maps an objectoriented definition of data to a relational database containing that data. Cross-Site Scripting

Agile Applica*on Security Task

17


AHribute Sprint Name JIRA Agile URI Confluence URI Descrip*on

Detail

Sign-Off Role Developers SCRUM Master Product Owner Descrip*on

Names and Contact Details

Date

Agile Security Quick Start Guide This process aims to capture the data flows of the current sprint in order to generate firewall rules that permit these flows, document and improve the controls that are in place to mi,gate aPacks them and ensure the system integrates into the opera,onal environment in a way that can be measured and monitored. For the components that are the focus of the current sprint/epic, here are the respec,ve tasks: Developers •

Architecture Diagram: graphically, textually, preferably both. This can be in the source code or using one of the tools suggested below.

•

Fill in the Agile Security Checklist: detail the data sources, sinks and any data synthesised ⁃ At a minimum: list the host/port, file transfers, creden,al handling and lifecycle. Without this, your component will not be able to communicate to the rest of the infrastructure. ⁃ Data Valida*on: Detail how the applica,on deals with data valida,on as this is a strong aPack vector. Consult the mi,ga,on sugges,ons below. ⁃ Op*onally: But very useful, document the data lifecycle, volumes, back pressure, privileges, privacy etc. The more informa,on that is accurate, the bePer we can ensure the applica,on is available and secure. Configura*on Files: List the configura,on files used by the applica,on and who controls these.

•

18

Agile Application Secuirty Framework •

PlaRorm Integra*on: Ensure the target system deals with issues such as resource exhaus,on, OS errors and logs an applica,on specific message ⁃ Authen,ca,on failures, input valida,on failures and resource usage are security sensi,ve events and need to be logged ⁃ Log issues using a unique token adhering to the applica,on development standard ⁃ For example, the standard applica,on specific message starts with a ~ (,lde) e.g. “~E_AUTH_FAILURE: Repeated authen,ca,on failure (count=5)”

•

Opera*onal Integrity: List threats to the opera,onal integrity of the system in terms of availability if you know any (e.g. Data input dependencies, missed transac,ons etc) STRIDE Analysis: Consider aPack vectors and decide whether they are applicable/ likely. If so suggest or seek mi,ga,on.

•

Scrum Masters •

Ensure that the Agile Applica,on Security Task reflects the applica,on accurately and does not contain irrelevant informa,on before

Product Owners

Applica*on Details Name Descrip,on Confluence URL Business Area Product Owner Host Datacenter Loca,on PCI-DSS

Notes

19

Agile Application Secuirty Framework Name Descrip*on Confluence URL Business Area Product Owner Host Data Centre Loca*on PCI-DSS

The common name of the applica,on. Give as much detail as you know of the applica,on and its business context A URL to the system documenta,on. Which business area owns the system Name of the individual or role that is responsible for the access control and privacy of the data hostname(s) of the applica,on servers that make up the system Which data centre hosts the applica,on servers Is this applica,on affected by PCI-DSS requirements. Special measures need to be taken to protect card data if this applies.

Architecture Diagram

20


System Descrip*on Describe each component of the system and how they interact.

Data Perimeter Analysis List the sources and sinks of data. Detail data that is created via summarisa,on, aggrega,on etc.

Sources Name

IP Address:Port

Descrip*on

Data feed name

NNN.NNN.NNN.NNN:N NNNN

Source system descrip,on

21


Sinks Name

IP Address:Port

Descrip*on

IP Address:Port

Descrip*on

Synthesised Name

Notes By default, all ports are closed, therefore you will, at a minimum, have to document the ports that your application requires.

Data Feed Detail For each data feed, complete the sec,ons that are relevant. See the sec,on below on Threat Mi,ga,on/Controls for instruc,ons on how to apply this each data feed.

AHribute Name IP Address:Port Number Transport (UDP, FTP etc) Descrip,on Access Control Aggrega,on Audit Authen,ca,on Configura,on Control Confla,on

22

Agile Application Secuirty Framework Encryp,on En,tlements Masking On Demand Update/Replay Persistence Privacy Resilience SOC Integra,on Tokenisa,on Versioning Whitelis,ng

Threat Mi*ga*on/Controls For each data feed detailed in the previous sec,on, consider the list of controls or threat mi,ga,ons for each. These are controls that are applicable to the business model of Global Blue and are not intended to be architecturally complete. The list will be augmented as new security controls and paPerns relevant to the opera,onal environment and business use cases are discovered. Mi*ga*on

Descrip*on

Access Control

Control of file access using low level opera,ng system mechanisms or higher level abstrac,ons such as document sharing (e.g. Dropbox), en,tlements etc.

Aggrega*o n

Data aggrega,on is a poten,al threat in that secrecy level can escalate significantly. For example, knowing that a fault in one product is not important: knowing that it exists across the product range is sensi,ve informa,on.

Audit

Data may have to be stored in a way which captures the audit trail e.g. customer trading records.

Authen*ca *on

Is the applica,on, user or service bona fide. Key in avoiding man-in-the-middle aPacks.

23

Agile Application Secuirty Framework Authorisat ion

Does the applica,on, user or service have the current privilege to perform the opera,on (aka en,tlements). This may be revoked in real-,me e.g. when a credit limit is breached.

Configurat ion Control/ Versioning

Revision control of the configura,on files is part of the change management process.

Confla*on

Data summarisa,on destroys informa,on and therefore can reduce the data sensi,vity but also provenance and accuracy making it difficult to ascertain correctness of informa,on.

En*tlemen ts

A token of en,tlement or bearer token can be used as an asynchronous authorisa,on mechanism in low grade systems. This is a par,cularly prevalent technique in market data distribu,on e.g.

Masking

Obfusca,on of data via subs,tu,on of informa,on with asterisk as used in credit card receipts. The least and most significant digits are s,ll visible.

On Demand Update/ Replay services

Request for the latest version of a resource such as a binary, configura,on or applica,on data. This can occur when a quorum or services loses a member that has to enter a recovery stage in order to rejoin the quorum.

Persistenc e

Storage: where, for how long, what access profile is required? how long should it be retained? What are the access requirements?

Privacy

Does the data owner know what you intend to do with their data and do you have the required informed consent [³], authorisa,on and permission to perform this ac,on.

24

Agile Application Secuirty Framework Resilience

Does this data require redundant delivery or capture? There are many paPerns here - from resilient disks to dual network cards and servers.

SOC

Security events can be generated by the applica,on that are sent to the syslog(1) or windows event mechanism. These events can be parsed by splunk and no,fied to a security opera,on center where a predefined process can be invoked. These can be login/logout, login failures, service level issues etc.

Integ ra*o n

Tokenisa* on

Data that cannot be allowed out of a specific zone e.g. PCI data or that subject to geo-legisla,ve constraint such as Swiss customer iden,fying data.

Versioning

Is a version history required to be maintained. This is different from configura,on control in that maintaining versioned data can mean that different version of a system can operate simultaneously but consuming/producing the correctly versioned data stream.

Whitelis*n g

By default, disallow access to all data sources. Whitelist data sources that the applica,on consumes. Data sources that the applica,on emits should be discoverable either by a web service, an enterprise data directory or by sta,c documenta,on.

STRIDE Analysis For each data feed in the data perimeter analysis, consider the aPack vector and decide if it is applicable to this data feed. Choose an appropriate mi,ga,on technique or request assistance from the SCRUM Master. Applica*on Name APack

Applicable? Mi,ga,on

Spoofing Tampering

25

Agile Application Secuirty Framework Repudia,on Informa,on Disclosure Denial of Service Eleva,on of Privilege

26