Security is becoming a key point in the development process as data breaches appear in the news every day and make company lose money and have reputation damage. Let’s see what can be done to protect the applications.
Security tests
We should consider at the beginning of each development which vulnerabilities may be added and code unit and integration tests to prevent them. E.g. check that only authorised users can access a resource, that users cannot send texts with scripts or images with viruses, etc. A good way to define them is using threat modelling that helps thinking about the most valuable assets and how hackers may try to get access to them
Code reviews
It is one of the most important ones as the people of the team can detect issues that automated tools may not be aware of. Some points to focus on are checking that the urls don’t contain confidential info like credit card numbers, checking that the person that is going to do a payment is the account owner, that all the endpoints are protected and only accessible by the expected users, …
Static analysis (SAST)
There are multiple tools that can be combined for analysing the code. Sonar can be configured with special rules to do security checks and detect e.g. that it is can be hacked using SQL injection, and there are multiple tools that do additional checks like ensuring that all the libraries are secure like Snyk or Dependency Check, checking if they appear in CVE lists (known vulnerability lists). For applications deployed using containers (via Kubernetes or similar) it is important to check that the images are secure
Dynamic analysis (DAST)
Some issues can only be detected when the application is running. E.g. cross-site scripting or security headers configured incorrectly like the CORS ones. There are some tools specialised on certain types of issues (e.g. looking to the headers), but there are others like Burp or ZAP that contain many types of attacks and can be first run locally to learn how the application works and then run in the pipeline to check that all the pages are secure. They are used by hackers and penetration testers, so passing their tests give some confidence about the status of the application. These tests may taken from minutes to hours to run so some of them can be added to the standard deployment pipelines while others are more suitable to run on separate overnight jobs.
Introspected analysis (IAST)
SAST and DAST work great but they look applications from outside, so they may flag false positives and not find some issues. There are some security tools that allow to inject an agent (a monitoring component) inside the applications that checks that all the code is secure and it handles properly requests that may contain potential attacks. This can run both as part of the pipelines and locally integrated with the IDE so developers notice issues as soon as possible.
Real-time protection (RASP)
Similar to IAST but for applications running on production and pre-production environments. An agent can monitor all the traffic the services receive, the queries they do, … and detect any unexpected pattern or unusual query. They have the advantage of looking to real traffic but they may detect issues too late (when code is already live and already used) and it may impact performance, so it may not be suitable for all types of applications.
Penetration tests
Most companies do both internal and external security audits in which professional white hackers try to break into the websites or apps as users, and try to perform actions they are not allowed to do. Depending on how critical is the feature to test, it can be done before very release or every few of them.
Teams to support it
Most developers don’t know enough about security and are more focused on implementing features than on doing it in a secure way. Due to this, it is important to have teams focused on helping and encouraging them to follow security best practices. Some of these teams are:
- Security committee: a team of experts that decide rules and standards to follow across the company to protect it and to define what to do in case of issues.
- Technical security: focused on building security tools or adapting existing ones, and also on monitoring that teams use them effectively.
- Security champions: developers interested in security that help the development teams in their area with everything needed about security and push them to follow best practices.
- Blue/red teams: help protecting and simulate attacks to ensure that vulnerabilities are detected before hackers find them, and can find other types of issues like open ports, insecure databases (mostly the ones that are usually hacked like MongoDB or Elastic Search)…
Consultant and security champion specialised in Java, with experience in architecture and team management in both startups and big corporations.
Disclaimer: the posts are based on my own experience and may not reflect the views of my current or any previous employer
Nice write up Raf. Security is so important and too often considered as an afterthought in big projects.
Spending some time with your team to learn some basic hacking techniques and tools can really help to change your mindset to that of an attacker. It is a great way to get a fresh point of view and opens your mind to all the vectors you need to consider.
Pingback: Security challenges of cloud native applications | IT and startup life
Pingback: The path to the Cloud | IT and startup life