API Security Matters: The Risks of Turning a Blind Eye – Source: www.securityweek.com

I have the good fortune of traveling a fair bit to meet security teams within businesses that span different sizes, industry verticals, and geographies.  During these travels, without fail, I find myself having fascinating conversations that are very grounding and informative regarding the issues and challenges that these security teams are grappling with. As you might expect, these issues and challenges evolve over time as certain ones are addressed and move lower in priority and other ones emerge and become top of mind.

Not surprisingly, one topic that has come up repeatedly in the recent past is API Security.  To be explicit (and hopefully clear), by API Security, I mean the full lifecycle of API Security. This includes:

1. Code-Based Discovery
2. Vulnerability Analysis
3. API Discovery
4. Preventive Controls
5. Continuous Security Monitoring/Detective Controls
6. Response/Mitigation
7. Implementing Lessons Learned

While there are likely many ways in which one can break out and enumerate the important topics contained within the somewhat loaded statement “API Security”, I find the above framework helpful.  It allows us to wrap our heads around the different dimensions we must consider when looking to protect and defend our applications and APIs.  It also allows us to understand how critical the visibility and awareness provided by steps 1-3 are to our continual success throughout steps 4-7.

Indeed, many security teams are well aware of this and, thus, are quite interested in obtaining visibility and awareness (steps 1-3) to be used alongside and facilitate their efforts to secure their applications and APIs. That doesn’t surprise me at all.  What does surprise me are the security teams that seem to want to do exactly the opposite.

What do I mean by this? Believe it or not, there are security teams that seem to want to, like an ostrich, stick their head in the sand. The rationale that I’ve heard is that when a security team knows about a problem, it becomes their responsibility and their issue to deal with. On the other hand, if large portions of the infrastructure and security issues around applications and APIs are unknown, security teams can remain blissfully ignorant.

While this type of approach may sound attractive and tempting at face value, it is not so in the least. Why? While there are likely many reasons, I’d like to offer five here:

1. Responsibility: Most of us are quite familiar with the phrase, “security is everyone’s responsibility.”  Everyone needs to take part in securing the business, including its most sensitive data and its most critical assets. Above all, the security team needs to take a big part in this effort. Regardless of whether or not being aware of and learning about issues will make our work lives a bit more difficult, we have an obligation to be in the know. Shirking that responsibility to make our lives a bit easier can have disastrous consequences.
2. Risk: Simply put, unknown unknowns introduce risk. More than that, they tend to result in the most serious and damaging breaches, intrusions, and incidents. I’ve seen, many times throughout my career, businesses get attacked through vectors they were unaware of and had no visibility into.  This lack of awareness and visibility was unintentional in those situations, and it still resulted in a load of trouble. But for a security team to willingly and intentionally put the business into this type of situation? That seems irresponsible and negligent to me, at best.
3. Ownership: When it comes to security, someone needs to be the adult in the room and someone needs to take ownership. We don’t get to shirk responsibility out of laziness, self-preservation, or otherwise. While we don’t have professional oaths in the security profession, there is an unwritten rule that we are to act ethically, responsibly, and in the best interests of defending and protecting the businesses that employ us.  Part of this responsibility involves identifying issues, taking ownership of them, and acting as necessary to address those issues.
4. Pain: When a security team chooses to remain blissfully ignorant, it is only a matter of time until the headaches and pain will come. They always do, and when they do, they are often far worse than they would have been had issues been dealt with in a timely manner.  Kicking the proverbial can down the road can only work for so long, and when time is up, the consequences are severe.  Not only for us as security professionals, but for the businesses we are charged with defending and protecting.  In many cases, there is liability for the decisions and choices that were made.
5. Liability: Businesses are entrusted with and responsible for safeguarding the data of their customers, partners, and others. With this trust and responsibility comes liability – sometimes legal, regulatory, or financial in nature.  If a security breach, intrusion, or incident rises to the level of incurring liability, the penalties and consequences are generally far worse when it is discovered that a decision had been made to intentionally and purposefully ignore the issues at hand.  What if this intent and purpose is never discovered you ask?  Never fear – it always is.

Willfully ignoring important security issues to make our lives easier is, unfortunately, something that does happen in the security field. Doing so is not only professionally irresponsible, it can have devastating consequences. Rather than finding ourselves in an extremely difficult and untenable situation, we should open our eyes to the issues around us and work to mitigate them in a timely manner.  This is better for ourselves professionally and for the businesses that employ us.