Sunday, September 25, 2022
HomeDigital TransformationDeveloping for FedRAMP Pays Back

Developing for FedRAMP Pays Back


Getting an application or service security certified under FedRAMP – the Federal Risk and Authorization Management Program – is one of the hardest hurdles dev and ops teams can clear.

It’s so hard, that of all the enterprise services that exist in the world, only 276 are FedRAMP certified. But these are the apps that the U.S. government agencies (like the Departments of Justice, Commerce, and Education, and even some Department of Defense agencies) can use, so building an app to this standard can be lucrative. The U.S. Government can be a valuable customer.

It is difficult to maintain FedRAMP compliance when building a SaaS product, but creating a DevOps process for your dev and SRE (ops) teams together that allows them to stretch to FedRAMP can be worth it. Maintaining FedRAMP compliance means creating products with the highest security specs. The security standards of FedRAMP also include other solid security standards from NIST (National Institute of Standards and Technology) and FISMA (Federal Information Security Modernization).

A handful of Cisco products meet FedRAMP requirements and are listed in the FedRAMP catalog: Cisco WebEx, Cisco WebEx for Government, Cisco Unified Communications Manager Cloud for Government (Cisco UCM Cloud for Government), and Cisco Cloud Lock for Government. Other products are in the audit process.

To get a sense of what it takes to meet the FedRAMP standard and the benefits and opportunities that come from earning a FedRAMP ATO (Authorization to Operate), I sat down with Charles Randall, a former teammate of mine and a security expert at Cisco:

What was the biggest challenge your operations team needed to meet with FedRAMP?

Charles Randall: Our biggest challenge was container vulnerability remediation, which was only added to scope by the FedRAMP management office the month our audit was scheduled. It was an enormous change that pulled a large number of open source projects into scope, and even required some architectural changes. We are still struggling to deal with the consequences today.

How would you describe the difference in your application and operations security posture before and after starting the FedRAMP certification process?

CR: We started with a solid application security posture; good enough to pass ISO 27001/17 and SOC 2 standards. FedRAMP demands a significantly higher level of operational security, both technically and procedurally. Many of the security improvements we made to achieve FedRAMP compliance were applied to our commercial operations environments as well, ensuring world-class security for our customers and consistent processes and procedures across teams.

What are the key elements necessary for maintaining a robust ongoing monitoring strategy? Would these strategies make sense in a non-FedRAMP context?

CR: The key elements of a robust monitoring program are completeness of vision and a solid set of KPIs. Completeness of vision includes full compliance and vulnerability scanning across your entire asset inventory, as well as monitoring of application, system and network activities with a focus on anomaly detection. These strategies also make sense in non-FedRAMP context and were nearly universally applied to our commercial operating environments.

Do you use off-the-shelf tools to differentiate a security event from a security incident? Would you use these tools and approach if qualifying for FedRAMP wasn’t the objective?

CR: We are mainly using free open source software for security event management, complimented by the full suite of AWS security services. While we do expect growing adoption of machine learning, there is really no substitute for the expertise of operators and analysts with eyes on logs, continuously refining monitoring to achieve the highest possible signal to noise ratio. This is another case where we use the same tooling across FedRAMP and non-FedRAMP environments, because it allows us to re-use the FedRAMP work in our commercial environments, and maintain consistency between operating environments.

How do FedRAMP requirements affect application developers? Does their security posture improve as part of the audit process?

CR: FedRAMP requirements have an enormous impact on application development, at all levels. Every decision, from system architecture, to third-party component selection, all the way down to your choice of cryptographic ciphers, can have significant consequences while pursuing or maintaining FedRAMP authorization. Beyond technical decisions, FedRAMP controls also require mature software development processes and configuration management practices, with many requirements extending all the way to build/deploy pipeline and developer laptops.

What are the consequences of developers not adopting security best practices early in the value stream (as part of their daily work)?

Failing to adopt security best practices early in your product development cycle, or failing to integrate those practices into daily routines, could be disastrous, regardless of whether your organization is attempting to pursue FedRAMP authorization. It is well known that the cost of fixing software defects can be an order of magnitude higher or more in production versus development phase of the SDLC. While that is painful enough, when you factor in the potential costs of larger-scale redesigns that might be required due to security defects, the costs of security incidents, and the potentially catastrophic costs of a security breach, the choice becomes clear that addressing security demands early and integrating it into everyone’s daily routine is the best option. If that argument still is not enough to persuade you, consider that user data privacy regulations are now increasingly enforced, and often with enormous fines.

What would you recommend for developers who are new to secure coding and would like to get up to speed with best practices. Would you recommend training? Learning and adopting security specific tools?

All of the above. Secure coding is just….. coding.

 

Now read:

 


We’d love to hear what you think. Ask a question or leave a comment below.
And stay connected with Cisco DevNet on social!

LinkedIn | Twitter @CiscoDevNet | Facebook | YouTube Channel

Share:



RELATED ARTICLES

LEAVE A REPLY

Please enter your comment!
Please enter your name here

Most Popular

Recent Comments