In an episode of America’s Got Talent, an aspiring stand-up comedian puts on a despondent expression and sighs “I had my identity stolen. It’s okay. They gave it right back.” That’s funny, right? Except for the fact that in the real world it isn’t funny at all. Your identity is your cultural, familial, emotional, economic, and social anchor, at the very least. So, if your identity is stolen, you don’t get it back just like that. It’s a personal integrity catastrophe that’s very hard to recover from.
eID Forum 2019 in Tallinn
eID Forum 2019 – Shaping the Future of eID took place on 17 and 18 of September in the lovely Hanseatic city of Tallinn. The aim of eID Forum was to bring together representatives from the public (governments) and private (industry) sectors. They achieved a presence of more than 300 participants from 34 countries to share ideas and emphasise the urgency of facilitating trustworthy civil and business digital transactions across national boundaries.
The Forum focused on high-level overviews of the processes and technologies used to develop contemporary eID solutions. We noticed a technology-centric focus and marketing of ready-made solutions. The focus topics for this year were:
- a cross-border digital standard for mobile driving licences,
- the future of digital borders, and face recognition and its use cases in airports, and
Should you be able to identify yourself or just your right to drive?
Huge efforts are being made to standardise driving licences that can exist in a form other than paper or plastic. But first, what is an eID (e-Identity)? An eID is a unique and immutable digital proof of identity for citizens and for organisations. One’s eID is a right and cannot be suspended or revoked because it is akin to, for example, one’s birth certificate. While an eID’s core attributes must be fundamentally self-sovereign and immutable, a wide variety of attributes can be granted to it and revoked from it. For example, privileges such as holding a driving licence. And one’s eID must be multimodal for use across a variety of digital identification-dependent systems and communication channels.
In Estonia, one does not have to carry any type of driving licence with him/her; not a physical or a mobile version of it. If it is possible to identify the person, then all the needed information can be checked digitally (the right to drive, having insurance, etc). This data exchange has, of course, to be done in a secure way. In Estonia, these data requests are done over the secure data exchange layer known as X-Road, which Gofore has had a role in developing since 2015.
Challenges with interoperability and rapid technological change
The idea behind eID standardisation and interoperability is that government services become more user-friendly, flexible, convenient, and resilient to many kinds of risks caused by otherwise divergent designs and implementations. But despite the fact that electronic identification is regulated in the EU by eIDAS (electronic Identification, authentication and trust services), its implementation in different countries is progressing at significantly varying speed and scope. There was recurring mention by presenters of the urgent need for eID standardisation, whether it be de jure or de facto, and the need for cross-border interoperability of the various eID solutions already in existence.
At the same time, the main challenges concerning eID are, in our opinion, twofold:
- Technological advancements for eID (including secure devices and identification capabilities like face recognition) are evolving fast and we do not know how regulation could keep up in this race.
- Did you know that according to the World Bank Group’s 2018 #ID4D Global Dataset, an estimated one billion people around the globe do not have an identity that they can prove? So for them, provable identity is not just missing in the digital society, it is totally missing. Since they face difficulties in proving who they are, they do not have access to services requiring digital identity. Might we consider having oneself listed in population registers as a human right?
Such fast-paced digital evolution as presented and debated at eID Forum is affecting every organisation in some way or another. We can help you rise to the challenges of fast digital change that you are facing your business domain. We can support you with organisational and technological change. All these consultations are available in Europe or world-wide through your nearest location: Estonia, Finland, UK, Germany or Spain.
This blog series is split into four parts:
- General information of secrets management
- Example how to store secrets into a version control
- Example how to use encrypted secrets in CI-pipelines
- Security issue and threat analysis based on previous examples
I’ll provide a small threat and security issue analysis based on this blog post series and the examples used, case-by-case.
Compromised personal or service account cloud credentials
It is possible that some member’s or service account’s credentials are compromised one way or another.
Simple steps for protecting compromised accounts:
- Revoke and reissue credentials
- Regenerate API keys
- Look logs for unauthorised access and usage
- Remove unexpected resources on a cloud platform
At least the Google Cloud Platform (GCP) has its own detailed guide for compromised credentials which can be read here: https://cloud.google.com/security/compromised-credentials
Last but not least: always use the multi-factor authentication for personal credentials.
Reducing vulnerability to a key compromise
If an attacker gets access to the key and encrypted secrets then all the secrets can be exposed – well, game over. The attacker can take your skeletons from version control and use them to carry out harmful acts like exposing IP addresses, passwords, API keys or even something worse.
However, you can reduce vulnerability to a key compromise with a few simple things.
Don’t re-use keys too often
With proper secrets management, you should never use a single, “one-and-only”, key for encrypting and decrypting all the secrets you have. You should create a new key which has its own purpose and encryption and is only for specific data.
In this blog series, I’ve used only one key to demonstrate how Mozilla SOPS work. You could make environment or version control repository based keys which would make things harder for an attacker. In the Very secret development operations, part II: Storing skeletons into a version control -blog, there was an example of how multiple different keys can be used with environment-specific rules (Advanced usage – Creation rules configuration).
Rotate keys and remove old versions of a key
Key rotation is a simple method to prevent key compromise: the old version of the key is versioned to history and a new, primary version of the key is created. Only the primary key is used for encrypting (and decrypting) the secrets while the old versions of key are used only for decrypting the secrets. Still, an attacker can have an old version of the key and use that for data leakage – but not for long if you remove old versions of the key!
You can manually or automatically rotate or destroy keys in cloud platforms. GCP has multiple guides regarding key management like:
In the Very secret development operations, part III: CI-pipelines -blog, there was an example of how to setup rotation period for a key, so GCP rotates keys automatically.
With SOPS you can renew the data key from the secret by command:
For further reading about key rotation with SOPS: https://github.com/mozilla/sops#key-rotation
A person leaving the project/organisation
If a person is leaving a company or a project they can be a sort of security issue if they still have access to resources after they have left. You have to always revoke access to all systems and keys which they have used.
While SOPS handles access to keys automatically, you only have to revoke access to cloud platforms and servers where your keys are stored. GCP has a good guide for revoking access to different resources: https://cloud.google.com/security/data-loss-prevention/revoking-user-access
Also, remember to revoke access to a version control – like remove a member from a Gitlab group or project.
What could happen after a compromise?
As I mentioned earlier, an attacker could use a compromised key to make harmful acts like exposing IP addresses and passwords. But things can be even worse than that, so I’ll mention a few aspects.
- Loss of sensitive information
- Personal data
- Industry secrets
- IP addresses
- Financial losses
- Illegitimate financial transactions
- Compensation to customers
- Loss of reputation
After all, your business can close down pretty quickly after the security breach. So keep your skeletons well hidden and secure secrets with proper secrets management, follow common security practices and follow, or even create security policies for your business and project.
Why Do Threat Analysis
Well, why not? It can be that due to a lack of familiarity with or experience of doing threat analysis (aka threat modelling), there can be a certain reticence or fear of failing. But such reticence or fear of failing is unfounded. Firstly, you won’t be alone doing threat analysis as you’ll have the application domain experts with you; secondly, a rudimentary threat analysis is more useful than none at all; and thirdly, analysis competence will grow by following up on the rudimentary threat analysis in successive sessions.
The objective is secure-by-design (aka built-in security) and one of the ways to achieve that is to identify and mitigate design-related security vulnerabilities during the system or application design phase. The output from threat analysis will be a set of security requirements that must simply be fulfilled like all of the other requirements.
Note that security is one of the enablers of overall product and service quality, which customers and end users rate trust and reputation upon. Additionally, since the General Data Protection Regulation (GDPR) activated on the 25th of May, and since secure-by-design is an enabler of privacy-by-design, it is prudent to also query and scrutinise privacy risks and mitigations during threat analysis.
When To Do Threat Analysis
There is a timing element to threat analysis. Ideally, threat analysis is performed as soon as the architecture has been established and is sufficiently mature. It is critical to understand that, no matter how late in the development process threat analysis is performed, it is critical to understand weaknesses in the design’s defences.
The fiscal and temporal cost of addressing security issues will generally increase if the design phase misses security weaknesses, so it is much more useful (and more cost-effective) to begin the process of identifying potential attacks and associated mitigations as early as possible.
A threat model should begin when the major structures and major components or functions of the architecture are mature. Note that threat analysis is a useful exercise regardless of how close the system is to deployment or how long the system has been in use; but as said, the earlier, the better. Successive development cycles, as in the norm in Agile development, should include focused threat analyses when design changes are made and to gradually mitigate security risks that the system currently carries. Also note that there is a distinction between end of development and end of support, and even when active support has ceased, a proper threat model will bring clarity about the possible flaws in the system.
Who Does Threat Analysis
Optimally, the product owner, lead architect, lead developer, lead tester, and lead user experience designer should together perform threat analysis with advice and facilitation from a security advisor or consultant. For GDPR aspects there may also be involvement of the Data Protection Officer, who has formal responsibility for data protection compliance within an organisation. As well as having the various insights from each of these competence areas, it is a personal opinion that this cross-competence representation ensures a greater probability of broader security awareness exposure and sharing throughout the development team(s).
The Link to Requirements Engineering
Threat analysis should be planned and applied in conjunction with requirements engineering; in this way, the security requirements can be derived as an integral part of the overall requirements derivation process. The security requirements derived from threat analysis should be linked to related business case epics, use cases and user stories so that they simply become “requirements amongst others”, which helps to dispel some of the unfounded reticence and mystery around security requirements.
How to Do Threat Analysis
How do you want to do it? There’s no single perfect way to do threat analysis; open source and proprietary methods exist. But they all similarly strive to answer the following questions:
- What assets require protecting?
- Who and what are the threats and vulnerabilities?
- What are the controls to mitigate the threats and vulnerabilities?
- What are the implications of not securing assets?
- What is the value to the organisation?
A good threat analysis methodology is one that identifies potential security vulnerabilities and threats, and as an exercise is time-optimised, manageable and repeatable. Project artefacts used for threat analysis include (and are not limited to):
- Architectural diagrams (component and logical models)
- Data-flow diagrams (DFDs)
- User stories and use cases (and related misuse and abuse cases)
- Mind maps
- UI designs
Think like the attacker to understand the relevant threats to both security and to privacy. Use defined security questions to ensure sufficient threat landscape coverage. Use the following categories to understand who might attack the application:
- An ordinary user stumbles across a functional mistake in your application while using a web browser and gains access to privileged information or functionality.
- Programs or scripts that search for known vulnerabilities and then report back to a central collection site.
The Curious Attacker
- A security researcher or ordinary user who notices something wrong with the application and decides to pursue further.
- Rebellious types seeking to compromise or deface applications for notoriety or a political agenda.
The Motivated Attacker
- A disgruntled employee or contractor with inside knowledge or a paid professional attacker.
- Criminals seeking high stake pay-outs by cracking high-value organisations for financial gain.
Apply STRIDE To Classify Identified Threats
STRIDE is a classification scheme for characterising known threats according to the kinds of exploit that are used (or motivation of the attacker). The STRIDE acronym is formed from the first letter of each of the following threat categories:
- Identity spoofing is a risk for applications that have many users but provide a single execution context at the application and database level. Users should not be able to become another user or assume the attributes of another user.
Tampering with Data
- This is about how an application deals with untrusted data – treat all data as untrusted anyway! Examples of tampering are changing GET or POST variable values directly in the URL address bar, failing to check data integrity, and deficient client-side and server-side data validation. In the worst case, you can call it data sabotage. This relates to threats #1 and #7 in the Open Web Application Security Project (OWASP) Top 10 2017.
- Users may dispute transactions if there is insufficient logging and auditing of user and system events, or if you cannot track user activities through the application or from the audit trail. A properly designed application will incorporate non-repudiation controls such as tamper-resistant logs; it should not be possible to alter logged events. A note of caution here: in terms of the GDPR, only the required data to facilitate audits should be logged; do not log personal data if there is no explicit requirement to do so. This relates to threat #10 Insufficient Logging and Monitoring in the OWASP Top 10 2017.
- There are basically two types: a data leak, or a privacy breach. A data leak can be a flaw or be a malicious attack. The most common flaw is simply not using Transport Layer Security (TLS) and not enforcing HTTP Strict Transport Security (HSTS). This flaw provides entry points for attackers to steal keys, execute man-in-the-middle attacks, or steal clear text data from the user’s client (e.g. browser) and data in transit. Concerning privacy breaches, in the context of the GDPR due caution is required concerning the protection of personal data from accidental or unauthorised disclosure.
Denial of Service
- The Denial of Service (DoS) attack is focused on making a resource (site, application, server) unavailable for the purpose it was designed. There are many ways to make a service unavailable for legitimate users by manipulating network packets, programming, logical, or resources handling vulnerabilities, among others.
Elevation of Privilege
- Access control enforces policy such that users cannot act outside of their intended permissions. Flaws typically lead to unauthorised information disclosure, modification or destruction of all data, or performing actions outside of the bounds authorised by the administrator for the user. It is essential that the user cannot manipulate the human-computer interface (HCI) to elevate his/her role to higher privilege roles. This relates to threat #5i Broken Access Control in the OWASP Top 10 2017.
For further types of flaw-exploited attacks, you can refer to the OWASP Attack Categories.
Apply DREAD to Quantify Threats
DREAD is a classification scheme for quantifying, comparing and prioritizing the amount of risk presented by each evaluated threat. The DREAD acronym is formed from the first letter of each category below.
DREAD modelling influences the thinking behind setting the risk rating and is also used directly to sort the risks. The DREAD algorithm, shown below, is used to compute a risk value, which is an average of all five categories.
DREAD_Risk = (DAMAGE + REPRODUCIBILITY + EXPLOITABILITY + AFFECTED USERS + DISCOVERABILITY) / 5
The calculation always produces a number between 0 and 10; the higher the number, the more serious the risk. Here is one way to quantify the DREAD categories:
- If a threat exploit occurs, how much damage will be caused?
- 0 = Nothing
- 5 = Individual user data is compromised or affected
- 10 = Complete system or data destruction
- How easy is it to reproduce the threat exploit?
- 0 = Very hard or impossible, even for administrators of the application
- 5 = One or two steps required, may need to be an authorised user
- 10 = Just a web browser and the address bar is sufficient, without authentication
- What is needed to exploit this threat?
- 0 = Advanced programming and networking knowledge, with custom or advanced attack tools
- 5 = Malware exists on the Internet, or an exploit is easily performed, using available attack tools
- 10 = Just a web browser
- How many users will be affected?
- 0 = None
- 5 = Some users, but not all
- 10 = All users
- How easy is it to discover this threat?
- 0 = Very hard to impossible; requires source code or administrative access.
- 5 = Can figure it out by guessing or by monitoring network traces.
- 9 = Details of faults like this are already in the public domain and can be easily discovered using a search engine.
- 10 = The information is visible in the web browser address bar or in a form.
Implement Threat Mitigations
Fortunately, there already exists a body of industry-scrutinised application security requirements known as the Open Web Application Security Project Application Security Verification Standard (OWASP ASVS) that can be readily applied as security requirements for mitigating identified security weaknesses and threats.
Verify Threat Mitigations
An OWASP Testing Guide will help developers and testers to verify implemented security mitigations to the accepted risk level. By “accepted risk level” is meant that there may be residual risks that will be too expensive to mitigate beyond the value of the business case; project management or owners must be prepared to undersign residual risk acceptance.
Penetration testing should support verification and automated security testing should also be implemented to the Continuous Development/Continuous Integration pipeline using e.g. Checkmarx and Open Source Analysis security verification tools.
Also, verify with the Data Protection Officer that any identified privacy-associated risks have been sufficiently mitigated to the accepted risk level.
I think this is the most important advice; without the curiosity, threat analysis might not happen. As said at the beginning, don’t postpone threat analysis; be curious, jump right in, and learn it by doing it.
OWASP Application Security Verification Standard (ASVS) is an industry-respected open-source framework of security requirements that MUST be incorporated when designing, developing, testing and deploying modern web applications for digitalised environments. It provides the security verification requirements to address your defined security questions.
OWASP ASVS Level 2 ensures that business-level security controls are in place, are effective, and are used by business-critical applications to defend against vulnerabilities and against attacks. Security threats to Level 2 applications will typically be by skilled and motivated attackers who focus on specific targets using tools and techniques that are highly practised and effective at discovering and exploiting weaknesses within applications.
The objective is that applications are secure-by-design and secure-by-default.
Secure Design is King
OWASP ASVS requirements should be applied as a customisable security blueprint for identifying the relevant security requirements according to identified potential threats to business entry points, gateways, critical assets and credentials. The OWASP Top 10 provides a starting-point high-level summary of the very minimum security coverage required.
Bake The Security In
For each application, required OWASP ASVS requirements should be pinpointed during feature design and epics and stories planning in order to ensure that the required security controls are part of development from the outset.
How to start
The development team scrutinise the intended application or service design using the defined security questions as a guideline. This will identify the entry points, boundaries, components and interconnections and that are security-relevant.
The application team can then utilise the OWASP Application Security Verification Standard (ASVS) requirements to produce security epics and stories that can be managed as Jira tickets,
Do not expect perfection from the beginning – getting security right is difficult and it is a learning-by-doing experience – but doing secure design and development in a structured and traceable way using industry-respected methods and materials is already a good start.