15 Practices to Shield APIs from Attack: #8 – And Finally, Getting Started
Published: June 5, 2023
In this series we have looked at 15 practices to shield your APIs from attack, and shown how many of these practices directly protect us from the top three of the OWASP Top 10 attack vectors.
These practices are applicable to securing all kinds of software development and not just thwarting API attacks, but given the breadth of the problem, you might be wondering how to get started. This article will help you prioritize and begin applying these practices, especially if you have teams already building software.
Which practices are most valuable?
Of the practices we have covered, three stand out as starting points as they are fundamental to progressing to more secure software over the long term. These also appear most frequently when looking at the different attack vectors in the OAWSP Top-10.
The Agile Product Team, using a DevSecOps mindset, is the foundation of agility as well as the best place for security ownership: with the developers of the product, at the time of software creation. Working with a DevSecOps mindset requires an organization, as well as each individual team, to develop practices, technical (and soft) skills, and organizational support and mechanisms to enable the team to work effectively. Without improvements in all three of these areas, it is hard to get the full benefits of such a team, but many organizations around the world are tackling these challenges now to get the benefits of development agility and security.
Automated testing for any product that will be in market or service for more than a few months is fundamental, if the goal is business and software agility. They are especially reassuring during technology migrations and infrastructure upgrades to confirm equivalent function in the new code. Focusing some of these tests around security is most critical. Building software that can be tested, and building the automated programmatic tests to go with it is a goal that can be achieved over time. Software without good test coverage is just technical debt, or a legacy platform, waiting to cause trouble. The skills to reduce this risk are available and are worth the investment if security, quality, and reliability are concerns for your business.
Visibility into a software system is key to spotting security-related and unusual behaviour. It is also valuable with respect to tracing impacts of security events. Knowing exactly what transactions are occurring on a system, and how these transactions are flowing is a great start to observability, but pulling events into a place where they can all be analysed and correlated is even more valuable. These practices don’t just help with security, and their value is incalculable with respect to being able to improve a system, reduce time to resolve customer issues, and measure operational performance against SLAs.
How do I get started with these Practices?
There are many ways to get started. Your organization’s experience, and your team’s experience, will influence your direction, but, assuming you’ve not tried these practices before, below are some key ideas to get started with each practice. See the next section for where you can go for more advice and help.
DevSecOps Product Teams
- Build an agile team – it’s never too early to get started.
- Your agile team for one product needs to be no more than 10 people, who are fully dedicated to developing the product all the time. They will need a Product Owner too.
- Hiring good Agile Product Owners who understand software development is tough, but they can make all the difference.
- Bring in an agile coach to help the team, and your organization, with the change. Change is hard and coaches are experts at facilitating change.
- Some people start by modeling their existing work via Kanban boards, and adapting from there.
- Start small, and remember that it takes time and effort to work differently.
- Automate, automate, automate – CI/CD pipelines are a key practice in getting to DevSecOps, and these pipelines and deployment tools must ultimately be owned by the product team, and not by a separate group.
- There are lots of books on agility and adopting these practices, and many are worth reading. Here’s a guide to some of them, with The Phoenix Project being at the top of that, and my, list.
Automated Security Testing
- Adopt a tool or framework like Cucumber or Serenity BDD and just build a few tests across key areas of your product.
- Authentication steps are good.
- Testing is a mindset, and your product team needs to adopt the idea that their job is to break things that they have created.
- Developers of your product must be the key people building and maintaining tests, even though many developers have not taken ownership of tests before.
- Bring in an Automated Test Engineer to augment the team if the developers on the team are new to these ideas.
- Incorporate your automated tests into your CI/CD pipeline, and run them everytime you want to validate a build candidate to be pushed beyond the development environment. And when they fail, do not proceed with the push until they pass.
Observability and SIEM
- Encourage your product development team to include explicit logging for audit events, and include items like timings. In a micro services architecture, correlating these audit events can be made easier by services passing around trace or request IDs.
- Check out our eBook on the things to log for best security observability.
- Bring your logs into an Observability platform like Splunk Enterprise or Splunk Observability. These tools make it much easier to identify operational patterns, not to mention make short work of creating dashboards.
- Investigate building reports and triggers around your observability data in these tools.
- Start small, and look for obvious issues to report to your SOC (Security Operations Center).
- Take a long view: growing to more mature SIEM tools (like Splunk Enterprise Security) takes time and skills. See the next section for where to go for help.
Who can help my organization with this?
In addition to these work practices, there are plenty of tools and information available. OWASP is a great organization to look at for help, with their Top 10 reports, and their SAMM assessment (Software Assurance Maturity Model). If you’re concerned with API security specifically, OWASP is coming out with a refresh this year of their API-specific Top 10 attack vectors, and you can look out for a post from us talking about how these practices apply to those specific vectors in the future.
Even running these types of assessments, however, can be difficult, and adopting the above practices often takes experience and advice to be effective.
Bringing in expertise, and coaching can help tremendously with improving your security and in adopting these practices. Consulting support can also help you determine what is best for your organization, depending on where you are now. You might benefit from an audit or review of your current API security practices, compared to where you want or need to be, which can help focus your efforts and provide a roadmap for next steps. Taking into account your specific situation and current security exposure combined with looking at your specific business needs for scaling, security, business agility, and the features you may need to safely expose your specific API assets, can all help in making strategic decisions about the next steps your organiztion needs to take.
At Solsys, we help clients with these very kinds of decisions. We have workshop services available to help you assess your current API security posture and software development approaches, and provide some details on what might come next for you and your team. We can focus on your specific API security practices and identify gaps you might want to close. We also have a number of patterns across these practices that we have instrumented in our Center of Excellence and Innovation Lab that is super helpful in diving deeper into design options.
However you proceed, good luck with your journey to adopting better practices to protect your APIs from attack. Just being aware of the problems and some of the things you can do to start improving your software development puts you on the right path.
