If you have been working in the IT security industry, you have probably heard CISOs (Chief Information Security Officers) complain about how companies fail at improving their security and pentesters complain about how their findings are ignored by companies. Whilst there is clearly no one-size fits-all solution to such problems, in this post I will share some of my experiences (in the way in which my NDAs allow) at addressing such problems. This post is the continuation of my previous post on how using Gentoo has affected my philosophy when handling security issues.
In a way similar to how there are more active and passive approaches to report issues in software projects, there are similarly more active and passive approaches to handle security issues. An auditor or an information security officer can just be mere vessels and focus on making the relevant stakeholders aware of the issues (what I call a RaD, for Report and Discuss, approach) or they can be more proactive and try to provide clear solutions to address the concerns (what I call PaF, for Patch and Fix, approach).
The RaD approach is the one I have seen more frequently on most of the companies I have worked for. As a security auditor, most companies just expect a report detailing the security issues found. Similarly, most managers (and that includes all the different kind of security ones) are just expected to report issues to higher level management and give instructions to their subordinates, which in most cases can’t do anything to address the problem at hand. At times this gets even more complicated by the fact that an issue has to go through many levels up and down until it can be fixed.
Instead, the PaF approach follows a different philosophy. PaF focuses on trying to provide a solution instead of a problem as directly as possible to the person who can address it. That doesn’t mean that the follower should ignore the need of making management or customers aware of the issues they have and their impact, it means that said person should also take the extra mile and try to facilitate things to the people that can solve the problem.
For a security auditor, the PaF approach starts early during the project, during the first meetings trying to scope the system to be audited. In these auditors should try to gain knowledge not just about the target system but also about the different technologies it uses so they can provide a solution as accurate as possible. It should be quite obvious that saying “enable the secure flag on cookies” isn’t as effective as pointing the developer to the PHP documentation explaining how to do so and telling them to check the secure parameter there. To be able to do so auditors need to know all this information. In either case, such information will also be helpful during usual audit processes anyways. Also, auditors should try to understand what are the customer’s needs and risks, most often those wanting to hire an audit are well aware of which assets are more critical for the company and can provide ideas on what their “nightmare scenarios” would be.
The next step comes during the audit themselves. When auditors find an issue they should not focus only on thinking how it can be exploited and what the impact will be. Instead, they aim towards trying to put themselves in the shoes of the person that provoked the problem and thus, figure out what caused that person to make that mistake or oversee that configuration. On one hand, this will ease finding similar issues on other parts of the system, on the other it will allow them to provide a clear hint on how to fix the issue and prevent it from happening again. In a white box audit, or a gray box audit where auditors can access the relevant source or configuration, they should go a bit further than just providing a patch, trying to think also how they would test the system to try detecting this issue and similar ones and what should be done to prevent it from happening again. On a black or gray box system auditors instead try to use their knowledge to see what could be causing the problem so that they can provide a good indication of what the technician should look for to address it. Auditors should always keep notes of these thoughts as they will be useful later on.
The next step usually involves writing a report with all the findings that appeared. Here, auditors don’t focus only on: naming and describing the issue, providing a clear way to reproduce it and, providing some vague information of what it’s exploitation entails. Instead, they attempt to use the knowledge they have to go further. They try to explain what the impact for the organization will be so the it can properly prioritize the finding. Also, they try to provide as much information as possible on how the finding can be fixed (or even a patch if it is simple enough) so that the implementation costs sink significantly.
Finally, the most critical step is the debriefing meeting. Let’s face it, one can’t just sit down and explain a not technical person how to change a .NET application configuration to avoid modifications of the __VIEWSTATE variable. In a similar way a technical person may be unable to perceive the impact that modifying a user’s birth date can have on the company. Under RaD, auditors would usually meet stakeholders which are usually non-technical people. Under PaF they will do the same and focus on the business impact that their findings have. Once done with this meeting, PaF auditors will usually follow up, once management has had time to prioritize issues, with a debriefing meeting with their technical people. The objective of this meeting is two-fold: on one hand, they aim at letting auditors help the technical people understand (and maybe even address) the most critical issues and those that are easier to fix; on the other, it allow auditors to provide their technical expertise to help them understand how to fix the issues in a correct way and how to prevent them from happening again. Auditors should always be humble and empathic at both meetings, since they never know under which conditions the systems they audited were created. Maybe the organization’s non-tech people was unaware of the risks involved or their tech people was inexperienced or under too much stress and pressure. Therefore, it should be noted that a comment like “Ha! Ha! Pwned!” or “Noooob error!” is pretty much useless whilst, instead, something like “It’s common for companies to be unaware of this risk, but it is usually easy to address and I can help your team in doing so” or “Don’t worry, it’s common for beginners/people under stress to make such mistakes, you can address it doing this thing and you can try to prevent it in the future by doing this other thing” are more likely to have the issues solved soon.
PaF auditors, keep always in mind that they are unable to be so explicit in all of their audits. After all it’s impossible to know everything and they may be missing the specific knowledge needed to provide a direct solution. Even in that case they will usually be able to provide a pointer in the right direction on how to address the problems they find. To that matter, documentation on places like OWASP can be of great help when explaining how to address issues to the technical people that can do so. Auditors keep also in mind that following the PaF approach will require more time and effort from their side than just following the RaD one. They attempt to be clear about that from the first scoping meeting by explaining the customer that they are willing to help them address any problems that are discovered during the audit and how they intend to do so. Although at times customers will not want such an approach, most often they will appreciate having somebody to resort to as they may not have had anybody to start with. Auditors should also be clear about their knowledge and limitations, it’s usually a bad idea to write code in languages where one is lacking experience as one risks making the same mistakes one is trying to prevent. In such a case helping the technicians understand how the problem works and how it is usually fixed is better.
So far we have covered penetration testers and other similar roles that involve auditing security systems. But the PaF philosophy is also useful for people in management roles involving security. Unlike auditors, managers have a more clear picture of the internals of the company, their development processes and their assets and risks. This knowledge makes it even easier for them to prioritize security problems. If you add a bit of technical knowledge to the mix (that in most cases these people have), it’s easy to see how the PaF philosophy works.
Under a RaD philosophy most security managers are expected to make higher management aware of any risks found (maybe with a good risk analysis) and maybe communicate the issue to the technicians so that they can get it addressed. Under PaF, the philosophy changes significantly as managers use their technical knowledge to try to solve the issue with the resources they have available.
The first thing a manager following the PaF approach does when learning of a security problem is thinking. Under RaD managers try to answer the questions: “How bad is this risk for the company?” and “What will be the cost of addressing it?”. On the other hand, under PaF managers also try to answer questions like: “What is needed to address it?”, “How can I speed up the resolution process with the knowledge and resources I have?” and “What will be the cost of doing so?”. With these answers it’s easy for a manager to decide whether to get further involved into solving the issue and how to do so or just reporting and escalating it. Keep in mind that particularly serious risks should be reported as soon as possible before taking any other actions so the rest of management can prepare the company for such risks.
This decision isn’t trivial though as it depends on a lot of factors, it is common, specially on large organizations, that managers don’t have access, of any kind not even read-only, to the configurations or sources that should be changed in order to address the problem. Also, certain organizations keep clear role separations which may make proactively solving the issue at hand harder. Finally there may be other cultural, policy related, skill related and personal hurdles preventing managers from doing so. PaF managers should be aware of these so that they can try their best at addressing the obstacles when deciding their course of action. Managers should keep in mind though that, under PaF, their objective should be to be as helpful and proactive as possible in addressing the problem. Even if they can’t address the problem by themselves, they always try to enable those that can do so as much as they can.
If a manager decides to get more involved in the problem resolution that person should keep in mind that security isn’t an excuse to jump over policy. Usually policies are there to address risks and prevent problems from happening, if they cripple the organization then managers should follow the PaF philosophy and aid the rest of management to get rid of them, but they should never bypass them as in so doing they will become a (bad) example for their coworkers. This is particularly important if the organization has code review, testing or change lifecycle policies. Bypassing these can be very detrimental as if all goes well the manager’s coworkers will be enticed to bypass them to, whilst if things go wrong the manager will be made responsible of the impact and, independently of other impacts, become less able to drive change in the organization.
So how can a manager following the PaF methodology be more proactive? In an ideal world the manager will have all the required resources and access permissions to address the issue, but although this may be the case at times at small organizations this is usually far from the usual case. In such cases the manager should try to write a patch addressing the issue and send it to the technicians that can apply it along with an explanation of what it tries to solve and why. At times this may not be possible though, in such cases they should aim towards pointing the technicians in the right direction to address the problem and support them once they start doing so. In this process, managers try to be empathic and supportive with those technicians they get in contact with. After all, it’s a lot easier to get things fixed when they are easy to fix but it is also a lot easier when those that have to fix them are motivated.
Finally, managers should never forget about reporting the issue to higher management (whether it could be fixed or not). Being aware of fixed issues ensures management is aware of said persons work and helps them keep risk models up to date. Also, being aware of unfixed issues and why they weren’t fixed helps them become aware of the remaining risks and of the organizational hurdles that may need to be addressed to have a more agile organization able to adapt to changes and unexpected circumstances. As usual, managers should try to make sure higher management understands the impact these risks have (or had) on the company and what the costs for addressing them will be (or were). Managers should never try to scare higher management about the seriousness of the issue as that can be detrimental to the organization, instead they should focus on being sincere and clear.
In most cases, this kind of approach will be positive for the manager as well. After all, people tend to prefer leaders over bosses and PaF is more about being a leader than a boss. Having a supportive, empathic and facilitating security management will make technicians more prone to discuss security risks and mitigation approaches with them and ease internal information flows between the two sectors. It will also make addressing security issues smoother and faster which, at the end, is what PaF aims to.
And well, in case you, dear reader, haven’t figured it out, the “aggressive” sounding title is heavily inspired by PoC||GTFO. Hopefully this read will help you become better at handling security issues in your future.