5 Tips to Solve API Security Issues in Any IT Security Infrastructure
In a hyper-competitive environment, keeping up with customer usability demands often means adopting a hyper-agile development process. It’s a dangerous devil’s bargain. Security gets left on the cutting room floor in pursuit of highly responsive, first-to-market, code-to-customer feature flow.
Mobile and cloud applications increasingly rely on SaaS and APIs to quickly meet customer needs. It allows for more complex rich application logic without having to reimplement common integrations or reinvent customer experience and maintenance flows. It allows businesses to respond quickly. It allows for more adoption, quicker. But with each customer value point added, a new threat vector is added as APIs layer one after another. To deal with security risks for APIs, we need to solve for a few challenges.
The effects of siloed business logic are continually making security solutions ineffective or even damaging — building contention instead of harmony between DevOps and Security teams. For example, a security solution needs to know if it is normal to block users after a few failed attempts to log in. Does that block meet with your individual business data? Or, is blocking users an issue that will drastically disrupt business operations and affect revenue?
It could be, in the case of logins, that the business goals for an app means not blocking users after numerous failed login attempts. Granted, there are almost no scenarios under which you would want to have zero limits on failed login attempts. It would be security suicide. But the example serves a point.
And the problem goes deeper than the development not providing sufficient API documentation. Security solutions need to sync with business intelligence and design to understand the instructions and significance of data within any given application or service.
This article tackles five hazardously overlooked considerations for actually solving security problems surrounding APIs.
1. Total Security Thinking: Getting Buy-In Across Teams
Everybody benefits when security is not treated as an afterthought or a way to check off compliance requirements. On the flip side, if security is overly aggressive, it is definitely possible to block legal users, partners, or other stakeholders in a way that would ensure security — while running a company into the ground. Business understands what “business” risk is. They know what it looks like internally, to customers, company-wide, and among key players. The balance between security and business goals is part of ensuring businesses stay afloat. Independently, though, business teams are not technical enough to understand what that necessitates.
The problem is organizational across industries. There is simply insufficient language between business and technical teams. Awareness needs to increase in both directions — sharing awareness and goals cross-functionally. DevSecOps needs a seat at the table to ask questions of business teams and figure out what needs to be protected as well as fully realizing the impact of new developments. It’s more than simply sharing user data or business processes.
Communication is needed to make possible prioritizing technical actions. There needs to be more cross-functional understanding and trust between business and technology teams. That way business can relate to the technology teams what the priorities are. Likewise, security can help business teams understand the challenges security teams are facing.
Taking risk assessment out of the security silo is like establishing a preventative healthcare policy instead of trying to stop an unchecked virus after an outbreak. Security and risk need to be a more distributed consideration. In fact, security thinking has to go even bigger and become a companywide consideration as part of the way we think about business every day.
Only when business and technology teams both have seats at the table will the right understanding inform: (1) what exactly you need to protect; (2) with what accuracy rate; and (3) how much time and resources should be spent to protect any one particular application or service.
2. “Security as a Process” Model
Second, we need to be ready — at any and every time, for existing and unforeseeable, new security challenges. Security, Operations, and Development teams all need to be able to respond to incidents. We need to do backups and be able to roll out backups as needed. We need to better train teams to be able to deal with hacking incidents and whatever might happen. But, we cannot stop there. We need to increase security awareness to reduce the number of security flaws developers unwittingly introduce into their code.
The basic processes and best practices should be implemented and refreshed on a regular basis. It is impossible to build a static security solution, mostly because of the changing interrelationships and new versions of your own APIs that evolve as part of the business process.
To build security for process-based business, you need to build security as a process. That means everything should be repeatable and the monitoring tools should allow you to monitor in almost in real time.
Without a process to accompany the right tools, you will never get any results that are actually effective in protecting APIs or your overall business.
3. More than an Inventory: Business Logic for Security Design
Think of a warehouse of inventory and a traditional security guard crew; you definitely need to understand what exactly you want to protect and where it’s placed. (There’s a big difference between a fenced impound lot and a busy, metropolitan embassy.) For an API, deciding how we monitor that inventory also depends on understanding the placement (infrastructure) and relative value vs security of each element. Our API security inventory needs to be based on which version we used — that determines structure. And, it also has to consider why we are responsible for this service — it’s value or priority. Only at this point can we determine: (1) what represents a security incident for each of the APIs; (2) who will be responsible for these incidents and should be notified; and (3) what resources the protection of each service demands.
Ultimately, the simplicity of our inventory analogy fails if we don’t go back to the difference between evaluating an impound lot and an embassy. The difficulty is not the dynamism of all the comings and goings of various dignitaries, attaches, valets, and support staff of the later. It’s more about the complex history and motivations of each person there — and how they interact. In thinking about our API’s “inventory”, instead of geopolitics and culture, we can think of the technological and business logic.
The only way to fully protect a service is to understand the business logic that makes it valuable. It’s critically important for security solutions to understand the logic underlying the choice of a particular API, SaaS service, or information system. We need to understand the logic to ascertain whether something is a mission-critical service to the overall business program.
Security thinking around APIs is not about securing just an inventory — or even a dynamic inventory. We need to go outside security teams and after-the-fact solution thinking where the good guys are always two steps behind. We don’t want to be police. We want to be the secret-agent level heroes who protect and ward off any-level attacks.
4. Smarter Cybersecurity Allocation: You Don’t Need a Vault to Protect a Water Bill
A big question in security is making sure that costs, efforts, and resources expended to protect specific services or APIs are in line with how critical the service is to the overall application. There is another factor here. Some services, though fairly simple or low-cost, have a catastrophic effect if attacked.
A simple, inexpensive service can need disproportionate attention and protection. Consider a family car. Critical services for it to fulfill its function of transporting people to-and-from places are the engine, wheels, perhaps the shaft. We think of major, high-cost components. You may not think about oil as a critical part of operations since it’s so inexpensive and easy to replace. However, if you drive without oil in the engine, you will destroy the engine and end up with extensive, very expensive repairs. The context and impact of any functional element is extremely important. This is why security and business need to effectively coexist — symbiotically.
It’s not just a security environment; it’s a total business environment. Developers need to be in touch with business teams to understand that there is a mission-critical function to what they are developing. By understanding business goals, DevOps can ensure users do certain operations faster or within a time frame. It may not be a big deal in a non-banking context to have inactive users that remain logged on. So, determining how an app should function is about cross-departmental understanding.
Let’s say a developer builds a simple account management app and there is what would normally play out as a minor issue that affects the user’s browser. But in this case, the developer has not realized the application is for a crypto-exchange or bank. This seemingly minor issue could become high-risk and allow a hacker to take control of the user’s browser, like reroute the account or modify authentication cookies. Attackers count on minor issues in high-value environments for their own financial gain.
The simple truth is the amount invested in protection should be in-line with what a possible hacker would gain should this service or API be compromised. To do that the development and the security team both need to understand the business context of the application. This also saves resources. If your bike lock costs five thousand dollars, it’s probably not worth it.
5. Scale and Structure: Organization and Company Culture Can Weaken Security
Companies across the board experience security challenges, but the challenges shift depending on organizational influences, like structure and activity. Fortune 500 companies have different challenges than small businesses. The maturity of a company can also influence the security needs. No one can have a static security landscape. Scale and structure, as well as internal organizational elements like company culture, will influence how good your security is.
However, there are challenges to achieving truly comprehensive security common to their respective ends of the scale — startup to titan of industry.
Large Companies Create Organizational Stress-Fractures in Security
At the higher-end Fortune 500 corporations, the scale is too huge for any one person to have a grasp of all the business processes. And, it’s almost impossible to ask key executives and stakeholders to sit together in one room and even that would probably not help because of the nested and fluid organizational structures.
The result? Clashing priorities often throw security off-center. Each vertical answers what is priority or function a little bit differently, as related to their shared business. Especially as businesses scale, complex org structures increase internal friction. Comprehensive security of applications and APIs is a nuanced, enormous undertaking that often becomes kicked down the road.
Scale has to do with age, as well. To support a large company, you likely need to support a lot of legacy code and a lot of important technological and procedural elements introduced years ago, decades in some cases.
Hindering fully comprehensive security is that security work is never finished. It has to be dynamic to match the churning business environment.
Startups Struggle to Gain Security Stability As They Grow
Startups need to move faster than their engineering teams. Startups’ paths are fraught with unpredictable decision-making practices because they are all about moving faster. Security is non-existent or, at best, following instead of being part of the movement forward. Developers need to better understand that startups are based on a high rate of change. Even investors and founders may not be informed enough to prioritize and make security decisions with the speed they need to. In those cases, developers have to be able to forecast where the business, and its technology, is headed.
Security Challenges at Every Size
Across the board, there is a range, or balance, between security problems arising from quick progress and the challenges that surface over time with increased organizational complexity. For example, a company that has 10 years of history will likely face a couple of legacy project issues inside its code. At that age and size, it may also face problems like having four different business owners scattered across times zones and schedules. You cannot get the stakeholders together and talk over security very easily. You may also be large enough to have a new or growing team, meaning there are human integration problems.
These are going to be challenges for businesses: continually having to rethink, educate, update and invest in security because it is so fast moving.
Conclusion
APIs are central to the digital transformation and competitively conducting business to meet modern norms and market demands. This new way of delivering data and services must come with new ways of cross-organizational and collaborative thinking. Developers, Operations, and Security professionals need to work together with Business. It is the only way to establish truly comprehensive security as a process. Cross-functional communication is imperative to: understand application context and operational risks; and incorporate risk-focused thinking, security monitoring, and best practices throughout the API development and deployment process and throughout the application lifestyle.
Only once cross-organizational thinking that integrates Business and DevSecOps happens will there be a happy balance of risk, costs, values resulting in happy customers.
