how to build secure systems
How to secure everything?
Multiple ways to secure everything (not exclusive from one another, in contrary, may be complementary).
- security should be a process
- security should be testable
- security should be measurable
Social
🙈
- good practices on developer / ops password management
- good practices on securing the developer computer
- …
SSDLC: Secure Software Development Life cycle
🎯
SSDLC consists on 6 phases:
- security requirements
- sources of security requirement
- data classification
- use case and misuse case modeling
- risk management
- security design
- core security design considerations
- additional design considerations
- threat modeling
- security development
- common software vulnerabilities and controls
- secure software processes
- securing build environments
- security testing
- attack surface validation
- test data management
- security deployment
- software acceptance considerations
- verification and validation (V&V)
- certification and accreditation (C&A)
- installation
- security maintenance
- operation, monitor and maintenance
- incident management
- problem management
- change management
- disposal
1. Security requirements
2. Security design
Threat modeling
There’s no such thing as a system being secure, only being secure against a particular adversary.
This is why it’s important to understand who your adversaries are, as well as the motivation behind and capabilities of each adversary.
Consider non-human threats, too. If you’re asked to secure a painting in a museum, a fire may technically not be a security issue — but it’s something to guard against, regardless.
Also, study the history of attacks. If I was designing a prison, I’d learn about all the past prison breakouts that I could.
secure by design
Domain primitives
- immutable
- defined only by their values
- form a conceptual whole
- invariants are enforced at the time of creation, i.e. if a domain primitive exists, it is valid
Validation
- external input needs to be validated before it is used in the system
- validation should be done in the following order:
- origin: where does the data comes from?
- size: a payload of a millions characters should probably rejected without further analysis
- lexical content: only the right type of tokens should be allowed
- syntax: format validity, e.g. if it’s XML, check there is a closing tag for each opening tag
- semantics: part of the business logic
Entities
An entity has:
- an identity, so it can be distinguish from other entities
- can contain other objects, both entities and value objects
- to perform business logic, it needs to mutate state
- responsible of coordinating the objects its owns, including ensuring internal invariants
The following techniques help with this:
- consistent at creation: all parameters necessary for consistency should be provided in the constructor
- limited operations: don’t have methods that can do more than what is allowed by the business logic, e.g. instead of
setPaid, we can use amarkAsPaid - not sharing mutable objects: no leak references to internal objects
The three R’s
- Rotate secrets automatically every few hours
- Repave servers and applications every few hours, i.e. redeploying the same software, e.g. if an attacker has compromised a server, the deploy will wipe out the attacker’s foothold there
- Repair vulnerable software as soon as possible (within a few hours) after a patch is available
Secure by default
🚧
3. Security development
CI: Continuous Integration
🚧
SAST: Static Application Security Testing
Static Application Security Testing (SAST) is a frequently used Application Security (AppSec) tool, which scans an application’s source, binary, or byte code. A white-box testing tool, it identifies the root cause of vulnerabilities and helps remediate the underlying security flaws. SAST solutions analyze an application from the “inside out” and do not reed a running system to perform a scan.
https://www.microfocus.com/en-us/what-is/sast
SCA: Software Composition Analysis
The short answer is, SCA is an automated process that identifies the third-party components including open-source libraries that are used in software.
Two of the main uses are to evaluate if the product or the software that we are delivering adheres to the security and licenses, and to analyze the quality of the code.
dependency-track can be used for SCA.
Repositories
Are our package managers (e.g. Nexus and Docker registry) safe and secure?
4. Security testing
DAST: Dynamic Application Security Testing
Dynamic Application Security Testing (DAST) is the process of analyzing a web application through the front-end to find vulnerabilities through simulated attacks. This type of approach evaluates the application from the “outside in” by attacking an application like a malicious user would. After a DAST scanner performs these attacks, it looks for results that are not part of the expected result set and identifies security vulnerabilities.
pentests
Dynamic Application Security Testing (DAST) is an automated security testing tool used in cybersecurity to help detect vulnerabilities in web applications. Penetration testing, in contrast, is a progressive and static manual procedure to identify weaknesses in a system. It deploys the services of tech-savvy individuals to try to find weaknesses in applications and systems.
Penetration testing entails the hiring of professional security personnel who think and act like hackers. These individuals are professionals in breaching applications where they work like the institution’s security police. They operate in real-time, and the company can detect breaches and point out the specific weak points for the developers to seal.
However, one downside is that this method is quite costly; therefore, most institutions implement it a few times a year or just once. It is also likely to generate false negatives; hence, requires frequent testing to be sure. Besides, it is a complicated process that needs an informed staff to comprehend and relay the results. On the other hand, DAST relies on requests and feedback to determine any vulnerabilities.
https://cybersecuritykings.com/2021/07/28/dast-vs-penetration-testing-know-the-difference/
Recommendation
Costly, and not needed at the moment.
5. Security deployment
CD: Continuous Deployment
🚧
authentication / authorization to deploy
🚧
DevSecOps
E.g. automated tools like checkov
6. Security maintenance
Runtime
🎯
- business workflow
- application network / communication