As many companies transform to multi-cloud environments, managing firewall changes at the speed of development teams can be challenging. Teams across Adobe are constantly evolving cloud services to continue to delight our customers. But one of the major challenges is in helping to ensure that the firewall change requests to support their work happen efficiently and securely. We receive hundreds of access requests each month for access to services. However, manually reviewing each one can be a time-consuming process that comes with the risk of human error. We set out to try and mitigate this potential risk by automating as much of the process as possible.

Defining Requirements and Initial Testing

We started by assigning different levels of risk to various protocols and common design patterns. We knew we needed to automate identification of these protocols and design patterns as well as identify what kind of connections should or should not be permitted based on risk tolerance.

We used Microsoft’s STRIDE threat model to help identify the potential risks with certain requests. Examples of these higher risk activities are:

  • When users did not understand their data flows, they might request large port ranges
  • When users did not understand how stateful firewalls work, they might request reverse traffic access (i.e. from server to client)
  • When systems support legacy insecure protocols like FTP for file transfers, users might request these simply because they are listed in the documentation

We also used a risk assessment matrix to measure the total impact and likelihood of possible threats. If the risk of a request is higher than what is permitted by Adobe’s own established risk management standards, the request would not be approved by the tool.

We then developed a framework using Python scripting to meet these requirements. In the initial testing and acceptance phase, all automated decisions were manually reviewed. Once we were able to determine that automated decisions could be reliably accepted, we then deployed this framework for our lowest risk change requests.

Evolving the Framework

The framework is designed to be extendable so when a new potential risk is identified, it can be folded into the framework quickly. The framework runs on each new change request. We make updates when a new potential risk is identified or there is a specific set of applications to which we should provide more oversight. We regularly review the tool’s decisions to help ensure ongoing accuracy as we scale up usage. We also advise requesters when deployment patterns do not fit automatic approval criteria. We encourage them to consider lower risk options for their deployments. We also remind them that any request must meet all established security standards. Here are some examples of best practices the tool looks for in order to expedite approvals:

  • Specific source hosts provided
  • Specific destination hosts provided
  • Secure transports only are used (HTTPS, SSH, SFTP)
  • Registered services with matching data classification
  • Well-defined logging and monitoring access

Conclusion

We are still developing and evolving this tool in real-time as we gain more knowledge about the patterns in our development teams’ requests. So far, usage of this tool has saved a lot of manual review hours, improved turnaround time for developers that follow established good security development practices and helps reduce the overall risk level associated this very common request for ongoing cloud application development and deployment.

Ben Chinoy
Security Researcher

Jason Joy
Sr. Enterprise Security Engineer


Major Initiatives, Ongoing Research, Secure Product Lifecycle (SPLC), Security Automation

Posted on 10-22-2019