apidays LIVE LONDON - API Lifecycle Management - Avoiding Breaches By Securing the Development Process by Rod Cope

Editor's Notes

• #3: Abstract:   In the race to unlock new business channels and create more value, there is always a push to develop new APIs. But how do they get from idea to value? And how do you ensure that they are developed not only swiftly, but securely? Strict top-down control destroys speed, but no governance puts you at major risk of regulatory and compliance violations.   Any phase of your API lifecycle - from strategy and design to deployment and optimization – can be the source of vulnerabilities that enable malicious attacks and allow unauthorized access, unapproved APIs, and exposed data.   In this webinar, we explore the API development process: where it originates, how to secure it, and how to maximize automation while preserving developer creativity and speed.   Join Rod Cope, CTO of Perforce Software, and guest speaker Randy Heffner, VP and Principal Analyst from Forrester Research, Inc., as they discuss:   How new APIs originate from new business channels and new web and mobile applications Infusing security throughout the API development process Structuring API delivery workflows to both meet compliance demands and speed development Integrating with CI/CD/DevOps to automate and harden the API lifecycle  
• #11: Development Governance - ensure you aren't building same functionality multiple times - ties into Portal capabilities, approval processes - Akana can do it and very few others can - authentication, proxying, having a gateway, rate limiting - automating - not leaving a chance that a policy is not applied, not attaching the right policy, ability to attach policies to meta data Can your API platform really do all of this?
• #12: Lifecycle Coordinator highlights: Objective: automated API configuration and promotion through runtime staging environments – eliminate hands-on actions as much as possible and by doing so gain efficiency and reduce potential for error Automated API configuration - API architects can easily define configuration patterns to be automatically applied via extended metadata values Auditable promotion records – Lifecycle Coordinator records all API promotion activities across multiple iterations with full visibility to configuration changes between staging environments Configurable role-based gating – enterprises can easily specify RACI (Responsible/Approver/Commenter/Informed) roles into promotion workflows; these become part of the audit record Integration with CI/CD platforms (e.g., Jenkins) – Lifecycle Coordinator can act as either a master or a slave within an enterprise’s CI/CD architecture When you promote from Dev to Production, can change OAuth domain The keys are: Configurable role-based gating (make gating more generic) RACI - broken down into roles that people have in any governance process -- who is responsible for promoting something into next environment, who approved that, who comments on it / reviews it, who needs to be informed of it -- all of this concept is built into the Akana platform
• #13: This is just a sample – not fixed -- there can be as many tasks/approvals as you want.
• #14: Promotions are being initiated and governed by the Lifecycle Manager, which drives approvals. In each Promotion (gray arrows), you can change appropriate policies for each instance, and change Oauth domains in each stage.
• #15: We typically position this architecture to those who want to be PCI compliant or have a little more security than they are currently doing – i.e. “you need to be doing AT LEAST this much” Advantage of Akana – Lifecycle Manager (pink box) -- managing review/approval side of things before production, so the managers get a notice of a request to do this promotion, and it must be approved before a change is made. Not just about encryption, also about process and architecture.
• #16: Customer wrapped in Akana’s architecture We add gateways on top of interaction layer, add a developer portal, add these security/management services along with our Oauth server, etc.
• #18: The HTTP Malicious Pattern Detection Policy is used to inspect HTTP messages for content that could be considered dangerous to an API or web service. This policy can be attached based on the metadata (previous slide) If the message content matches any of the expressions identified in the policy as potentially dangerous, the policy rejects the message and returns a fault. This policy uses regular expressions to define the content that could be considered dangerous, that would warrant a message being rejected. Typical uses of this policy are for SQL injection detection or JavaScript detection. You don’t need to order your policies, like with other platforms.
• #23: Note: change “Asset Submission” to “API submission” if possible
• #27: Same slide title at step #3. Are they both correct?