Recently, a wonderful co-worker of mine was injured quite badly during his winter ski vacation. If I understood him correctly, another skier came barreling into him while he was on the slopes. This inflicted serious injury upon my co-worker, unfortunately, and he has a long recovery ahead of him. I wish him well and a speedy recovery.
Naturally, the other skier is at fault here, but my co-worker is the one left with the injury and the long recovery. You may be asking yourself what this has to do with information security. It is a fair question, of course, though I believe that there is an important security lesson we can learn here. Sometimes, regardless of who is at fault for a given issue, the security team is left with the consequences.
As most seasoned security professionals know, when there is a security issue, it is usually the security team that feels the heat. While the entire company suffers the consequences of a security incident, it is most often the security team that feels that pain most acutely during and after the issue. To help illustrate this point, here are five situations where others may be at fault, but the security team will be left with the consequences.
- Application Security: Application security is a challenge that many enterprises grapple with on an ongoing basis. The complexity of modern applications that have modular components spread across different environments only adds to this challenge. On top of this, security teams and application owners/developers don’t always have the most functional working relationships. As such, application security may not be as mature inside most enterprises as it should be. In many cases, application developers may bypass security protocols, processes, and procedures, despite the security team’s desire that they follow them. Yet when there is a security issue with an application, it is the security team who is called upon. As such, it is important for security teams to find ways to develop and nurture their relationships with applications owners/developers to facilitate building security into the application development lifecycle.
- Insider Threat: A malicious insider can purposely expose confidential, proprietary, and other sensitive data. A careless insider can do so unwittingly. Regardless of the insider’s motivations, the damage that results is the same, and it often causes grave damage to the enterprise in the form of incident response costs, regulatory fines, lost revenue, reduced customer confidence, and other such consequences. Regardless of who is at fault, the security team will be called to task when an insider threat incident occurs. As such, it is imperative for security teams to ensure that they have proper policies and protections in place to mitigate the risk that insider threats pose. This includes implementing technology solutions, where appropriate, to identify and mitigate insider threats.
- Compliance: While regulations and regulatory bodies vary by vertical and geography, one thing seems to remain consistent across both. The security team will need to respond to and remediate regulatory and audit findings. This generally requires either agreeing with the finding and providing a corrective action plan, or it requires disagreeing with the finding and providing evidence in the form of assertions. When the enterprise is interested in providing assertions that counter regulatory findings, the security team will get the call. When that happens, data and facts will be required – intuition and feelings won’t be enough. Security teams should ensure that they have the requisite visibility and telemetry data required to perform the necessary analyses and investigations. That is the only way that the security team can respond appropriately when regulatory findings come their way.
- Incident: As noted in the above point, when there is an incident, the requisite data will be required to perform the requisite analyses. No one will want to hear excuses around why the security team has been flying blind. Because of that, it is important for security teams to proactively push to get the visibility and telemetry data that they need to perform their duties. It may not be the easiest of initiatives, but it is essential.
- Investigation: When an incident occurs, the security team will be asked to investigate. Aside from the requisite data, this requires tools and training. If the security team has not been trained properly, it should remedy that by arranging for the needed training. If the security team does not have adequate tooling, a gap analysis should be performed to see where tooling is missing and those gaps should then be filled. The ability to perform a proper investigation when an incident occurs is a fundamental capability for the security team.
The security organization has never had it easy inside the enterprise. That being said, there are steps that the security team can take to ease the stress and burden on itself when an issue occurs and they are called upon. These steps include: building relationships across the business, ensuring that the requisite people, process, and technology are in place, and ensuring preparedness. When that is difficult, look to technology solutions to help. One thing is certain though, ignoring the need to be prepared to shoulder responsibility when an issue occurs is not an option.
