How many resources should be invested in security, and when?
Investments in security should be treated in the same way as other investments, e.g. in marketing, personnel, hardware or software. As in any of these cases, the fundamental questions should be:
- What can we gain in revenue by investing in security?
- What can happen if we do not sufficiently invest in security?
- How likely is it that an adverse event will happen?
The answer to these questions depends on a variety of factors, such as industry, company size, competition, company goals, etc. Despite this significant variance between companies, some advice has proven to be universal:
- Each security flaws found by a pentest that could lead to a data breach in a single step must be addressed immediately.
- Each security flaw with a high score, i.e. greater than 7, must be promptly incorporated into the work process.
- Depending on the industry, 10% to 20% of the development capacity must be planned for security in the long term.
We will normally convey such general rules to you in the final meeting, adapted to your situation.
However, the devil is often in the detail: What does ‘immediately’ mean? Should you test this patch extensively beforehand - which can delay the deployment of a patch - or can you apply untested patches, claiming that “it’s better to have an inoperable website than a website that loses customer data”? This choice between two different risks is a consistent theme throughout the entire management of security.
Fundamental documentation of risk management
This is where we offer you our consulting services: A senior consultant develops a list of such fundamental questions with you and answers them together with you so that you can then derive specific processes and instructions for action from them. Above all, however, our consultant will work with you to develop a process for dealing with such key risk management questions. This is because, just as important as the answer to such a question, is the documentation of all considerations and justifications for this decision.
We also help you to find the optimal form for this documentation. In many cases an Excel file will suffice, but for more complex situations we can help you select suitable software. Here you can rely on our experience and above all our independent advice, as we do not accept payments (kickbacks etc.) from third parties in any situation.
Such documentation of fundamental risk guidelines has a whole range of advantages:
- Corresponding derived guidelines - e.g. programming guidelines - are comprehensible to the developers and can therefore be implemented in the long term
- New employees can be specifically trained so that they follow fundamental guidelines from day one
- In the event of security incidents, management can prove that they have initiated appropriate security measures
- After each security incident, the implementation of the existing risk guidelines can be reviewed and, if necessary, both the implementation and the respective guidelines can be adjusted
- Further investments in software, services, etc. can be evaluated against these risk assessments to ensure that all steps in the value chain guarantee the required security
Continuous documentation of current risks
In a second step, we also help you to incorporate current risks found during a pentest into this documentation. In this way, you always have an overview of which risks have already been addressed and which risks are still open.
In the long term, your risk documentation will help you to optimize the security effort in your development process. If the list of outstanding issues decreases in size, you can be sure that your efforts are sufficient at the moment. However, if new risks are added faster than old risks are mitigated, you will either have to adapt the process or simply allocate more resources to security issues. You can also find duplicates more quickly and combine measures - which almost always leads to greater efficiency.
Finally, when new exploits become known, you can quickly analyze whether you are affected and which components need to be replaced or patched to reduce your attack surface.
Transformation based on risk management
Frequently, the first penetration test that a company carries out perpetuates an understanding that continuous work on security is necessary at all levels. In this situation, there is always a significant mismatch between the tasks to be implemented immediately and the resources available. Even if the readiness and the financial commitment are present, the implementation of remediation measures simply takes time.
The sheer volume of risks also often creates new risks, e.g. that individual issues are overlooked or that the risk assessment itself takes too long.
In this critical initial phase, we help you to carry out a triage in order to quickly identify the highest impact risks and at the same time not overlook anything. We can also show you various options for action that are not self-evident, but can help you to prevent the worst scenarios very quickly and with little effort.
For example, a customer was using an outdated and therefore vulnerable library to manage business rules. The ostensible solution would be to update this library to the latest version, but in this particular case this was too time-consuming as massive differences in the syntax and semantics of the business rules had been introduced between the current version and the version used. It might have been possible to rewrite these rules, but the technical testing would have been unacceptably time-consuming.
We therefore introduced an external firewall for the customer (in this case Akamai) and mitigated the vulnerability with a customer-specific rule in this firewall. This was not a perfect solution, but it enabled the customer to mitigate a serious security vulnerability within three days that would otherwise have taken months.
Thanks to our extensive consulting experience, we can often massively reduce the time it takes to restore secure operations.