The 1954 novel, “I Am Legend,” played a major role in the development of the modern zombie and vampire genre. As far as the main character, Robert Neville, knows, he’s the last survivor of the pandemic that turned everyone else into “vampires” (though they resemble more of what we think of as zombies). One distinguishing mark of the novel was the scientific explanation behind the disease, and the accompanying biological fix.
How does this relate to APIs? Two dangerous types of APIs are Zombies and Shadows. Let’s talk about how these foes present serious issues and how – like Neville found – there are non-magical, rational, logical, and reasonable fixes.
Zombies and Shadows
A zombie API is an API that has been abandoned by an organisation, lingering and forgotten. A shadow (aka Rogue) API is an organisational API that has been created but never documented, so it remains unknown by the organisation. The two are similar because, by not being in the official inventory for updating, securing, or removal, they present a serious liability regarding security, compliance, and privacy.
The difference is that the zombie API was at one time approved by the organisation, while the shadow API was never officially approved. Which is worse depends largely on how the API is being used and where it’s located. Internal and test APIs can be harder to access from the outside, but if a shadow internal API was created by a threat actor who now has active 24/7 access internally, then the internal shadow is a much higher threat than the public-facing zombie that no one has discovered.
A recent survey demonstrated that the zombie API tops the list of API security concerns, with “54% indicating that it is of high concern.” While shadow APIs appear to be less of a concern for those surveyed, this may reflect their organisational risk appetite.
Gamification
Remember the Choose Your Own Adventure ® series? (Pick Your Path ® was another one that I remember) It’s been around a long time, and a few years ago the Infosec Institute gamified information security by creating the “Zombie Invasion” game. Since then it’s moved on to “Deep Space Danger.” (One can also design one’s own storyline)
Let’s try a quick story of our own making, one that deals with the importance of following the Secure Software Development Lifecycle during API development and how that can reduce or allow zombie and shadow APIs. You can replace Zombie with Shadow to deal with either API risk.
Zombie Attack: Secure Your Code or Face the Consequences!
You’re a software developer working on a critical project that could save lives. You have been tasked with creating an application to help people defend themselves against a zombie apocalypse. You must follow the Secure Software Development Lifecycle (SSDL) document to ensure that your code is secure and cannot be hacked. However, if you don’t follow the SSDL, your code may be vulnerable to attackers who want to use it for their own evil purposes.
Chapter 1: Start of the Project
You have just been assigned to the project. Do you:
- a) Take some time to read and understand the SSDL document before you start coding (go to Chapter 2)
- b) Start coding immediately without reading the SSDL document (go to Chapter 3)
Chapter 2: Follow the SSDL
You read the SSDL document and start following the guidelines. You use secure coding practices, perform security testing, and implement access controls. Do you:
- a) Continuously monitor your code for vulnerabilities (go to Chapter 4)
- b) Think that following the SSDL is too much work and stop following it (go to Chapter 3)
Chapter 3: Ignore the SSDL
You start coding without following the SSDL document. You take shortcuts to save time and do not perform any security testing. As a result, your code is vulnerable to attacks. Do you:
- a) Recognize your mistake and go back to Chapter 2 to follow the SSDL (go to Chapter 2)
- b) Continue with your coding, ignoring security risks (go to Chapter 5)
Chapter 4: Secure Your Code
Your code is secure, and you detect a potential attacker trying to hack your system. Do you:
- a) Report the attack to the security team and work with them to fix the issue (go to Chapter 6)
- b) Ignore the attack and hope that it goes away (go to Chapter 5)
Chapter 5: Attack Happens
An attacker takes advantage of the vulnerabilities in your code and gains access to the system. The attacker uses your application for their own evil purposes, causing chaos and destruction. You failed to stop the attack and must face the consequences of your actions.
Chapter 6: Defend Against the Attack
You work with the security team to defend against the attacker. You fix the vulnerabilities in your code and implement additional security measures. You have successfully defended against the attack and prevented the attacker from causing any harm.
The fix: Crash Testing
Frontal-impact, side-impact, pole, rollover – these are just a few of the many tests performed for vehicular crash tests. A lot of resources are put into making automobiles safer to drive. Are the tests flawless? Like everything other test, no – crash tests dummies have historically been based on average American males who is 5’9″, 170lbs, and does not consider the average female (about 5 inches shorter). While testing can be improved, that doesn’t discount the usefulness of the tests.
It’s the same with securing APIs. No amount of testing APIs will cover all scenarios, but some testing is far better than no testing.
Crash test your APIs but avoid a myopic approach. While some testing is good, the process must improve. While designed for manufacturing and TQM (Total Quality Management), a popular concept that can be applied to API design, development, and testing is Kaizen. Without some method of improvement, testing quickly becomes a form of laziness, introducing further risk.
Buried Treasure
As with any security program, the primary activity is asset inventory – you can’t protect what you don’t know you have. Just like mining for gold, looking for those forgotten and unknown APIs may be resource-intensive, but the results will be worth their weight in being able to protect the invaluable resources that your customers have entrusted to you, and, more importantly, upholding one of your most important assets: your reputation.
About the author:
Ross Moore is the Cyber Security Support Analyst with Passageways. He has experience with ISO 27001 and SOC 2 Type 2 implementation and maintenance. Over the course of his 20+ years of IT and Security, Ross has served in a variety of operations and infosec roles for companies in the manufacturing, healthcare, real estate, business insurance, and technology sectors. He holds (ISC)2’s SSCP along with CompTIA’s Pentest+ and Security+ certifications, a B.S. in Cyber Security and Information Assurance from WGU