As companies embrace all aspects of a digitizing world, many of them have already become comfortable and proficient at developing ways for others to consume their digital services. Microservices and application programming interfaces (APIs) are two ways of allowing other firms to “plug” your digital services into whatever it is they are offering, such as a retailer providing APIs to any web developers so that customers can browse and shop from within a completely independent website (this piece has more).
But now information risk teams are automating security governance by providing security capabilities via micro services and APIs. By reducing the effort required to fulfill security requirements, information security teams are able to help software development teams meet speed-to-market goals and limit the governance burden at the same time.
Taking a Holistic Approach to Automation
This automation approach offers multiple types of security components to developers. They tend to include three things.
- Code modules or constructs available to developers in a code library.
- Microservices (i.e., a software architecture pattern that separates distinct functional components so they can be independently built, changed, and deployed and that communicate with each other through APIs) and APIs that “expose security capabilities as a service” and make security easy to consume.
- Security tools that directly plug security capabilities into the integrated development environment.
Information security teams like using microservices and APIs because of their simplicity and ease of use. Traditionally, when a developer needs to build a security feature (e.g., authentication, authorization, encryption, logging, backup) into an application, he or she either builds it from scratch, finds a development pattern and customizes it, or simply doesn’t do it. These approaches are either too time-consuming, too risky, or require specialized security engineering skills that the average developer lacks.
Essentially, microservices and APIs give developers “building blocks” to create secure applications. By standing-up APIs for common security services, such as authentication and encryption, firms help their developers to incorporate security functionality into their applications without additional security training.
How to Decide What to Build
Information Security functions begin with 5-10 “commodity” security functionalities such as authentication, authorization, encryption, logging and monitoring, data backup, and others. These functionalities are essential because they are used by a large portion of the application portfolio. Further additions are then evaluated based on business demand.
Certain information security teams in CEB’s networks find so much value in this approach that they don’t shy away from building an API even if it can only be used one or two times. They still see the value because they feel there will be additional use cases in the future, and even if that doesn’t end up being the case, it’s still filling an immediate gap in business demand.
How to Get Started
Information security teams are taking different paths. Some members buy a single API with Information Security’s budget. They then enlist early adopters (i.e., software development managers) to support conversations about funding for additional ones. Others sit security architects, technical developers, and architects in close proximity to make sure all the skills required are in one place.
Jeremy Bergsman is a practice leader at CEB, now Gartner. Read more blogs from the firm here.
