The world is becoming more and more digital and the amount of data shared through the internet increases every single day. From time to time, certain groups of people, or sometimes just a single individual, carry out attacks on large companies in order to steal information, which they then use to ask for “ransoms”, or sell it to third parties for a large amount of money (or crypto-currencies).
No matter what kind of project developers work on, their task should always be to produce readable, maintainable, and above all, secure code.
Secure by Design
One of software development projects’ most common mistakes is leaving security aspects to the last minute. For example, there are cases where the last task before going live is to perform penetration tests, which is very good, but not enough.
It is very common that companies only focus on the development of new functionalities that bring some kind of value to the business, leaving aside important aspects such as the development of exhaustive tests (integration, load) and, of course, security aspects. All of this should be taken into account from the very beginning of the project, and reserve some capacity in the planning of the teams so that they can work on it with enough time and dedication.
Security must be taken into account from the design phases of the application, identifying what are the weak points that need more attention and taking action during all phases of the project life cycle.
A “safe system” must comply with the CIA-Triad:
- Confidentiality: Information must not be made available or disclosed to unauthorised entities
- Integrity: This is the property of safeguarding the accuracy and completeness of attacks.
- Availability: Is the property of being accessible and usable upon demand by an authorised entity
In addition, the secure design assumes that the exploitation of threats is taken for granted. In addition, it establishes the following principles:
- Least privilege: Every user or module is given the least amount of privileges necessary
- Defence in depth: Do not rely on a single measure to keep attackers out
- Fail securely: If your system fails, fail securely and do not expose more information than needed in stack-traces or logs.
- Detect and record: Your system must be able to detect unusual events and record them.
- No security by obscurity: You cannot rely on being obscure to be secure. Assume you have an open design, your software must be secure even if attackers know the whole architecture.
- Don’t trust: Assume that everybody wants to damage your system
- Keep it simple: Implementing more than what has been specified opens up space for new vulnerabilities. Minimise the attack surface.
Defensive Coding
An experienced programmer knows what countermeasures must be applied when developing certain functionalities to prevent software from containing vulnerabilities.
- Know your APIs: Using an API or library in the wrong context may result in vulnerabilities. Copying internet examples without a complete understanding is a mistake!
- Attack surface: Any input is a possible entry point for attackers. Do not increase the attack surface beyond what is needed to implement the required feature! For example, remove any unnecessary code from your project. If it’s not being used, it might still be exploited to access your system!
- Complexity: We cannot secure what we don’t understand.
However, it is not always easy to detect this, which is why it is very important to have our code reviewed by other developers. Thankfully, there are some tools like Spotbugs that can be used to automate the code analysis.
It should also be taken into account that projects usually contain third-party libraries to which we do not have access, and may contain vulnerabilities. This is why certain tools perform a static analysis of the code (SAST), as well as the libraries imported into our project.
Security Testing
SAST (Static Application Security Testing)
SAST tools are a set of technologies designed to analyse the application source code, byte code, and binaries for coding and design conditions that are indicative of security vulnerabilities.
These tools analyse applications from the “inside out” in a non-running state (white box):
- Many errors can be found
- Precise feedback (line of code of the error highlighted)
- Errors can be found in the early stages of the SDLC
- Some security problems are hard to find statically
- Often the high amount of false positives
DAST (Dynamic Application Security Testing)
Designed to test and detect conditions indicative of a security vulnerability in an application’s running state (black box). Most DAST solutions test only the exposed HTTP and HTML interfaces of WebApps. However, some solutions are designed specifically for non-web protocols:
- Can find semantical errors
- Environment misconfigurations
- Represents the “hacker” approach
- It needs a running application
- Resource heavy
IAST (Interactive Application Security Testing)
IAST tools work in a different way than static or dynamic tools. They leverage information from inside the running application, including runtime requests, data flow, libraries and connections to find vulnerabilities accurately (grey box).
Establish a Mitigation Plan
The CVSS (Common Vulnerability Scoring System) is a rating method for vulnerabilities that assesses their severity using 3 groups of metrics:
- Base metrics: How difficult is it to exploit the vulnerability? How are the CIA properties affected?
- Temporal metrics: Is there an exploit already? Has the vulnerability been covered since?
- Environmental metrics: How does the vulnerability affect your specific environment?
When vulnerabilities show up, it is recommended to establish an action plan and this is a very good starting point. We should rank vulnerabilities in order to decide “when” and “how” they have to be mitigated.
OWASP
The Open Web Application Security Project is a non-profit organisation that aims to educate developers about software security.
The OWASP recommends using techniques such as manual inspections and reviews of people and processes, threat modelling, manual and automatic code reviews, and penetration testing.
These start at different points of the SDLC (Software Development Lifecycle) and can intercept development errors with regard to software security at an early stage.
To make developers’ lives a bit easier, there is a tool named OWASP Dependency check, which attempts to detect publicly disclosed vulnerabilities contained within project dependencies. It does this by determining if there is a CPE (Common Platform Enumeration) identifier for a given dependency. If found, it will generate a report linking to the associated CVE (Common Vulnerabilities and Exposures) entries.
Summary
I hope this helped you to better understand some security aspects and how developers should think before starting to write code.
There are some tools that can be easily integrated in our projects to perform static analysis or dependency checks, and everything automated through pipelines.
