2015 06-12 DevOpsDC 2015 - Consumer to Collaborator

Editor's Notes

• #3: GREG: If you’re talking FISMA, FedRamp, DoD STIG, or PCI, security is feels as procedural encumbrance when it comes to DevOps. Greg: Anyone doing it experiences this burden. Greg: We’re going to tell you a story about an emerging practice that’s changing our relationship to security and compliance from 3 perspectives that span the software development. SHAWN: The guy who writes the policies like DoD STIG and NIST. Maintains machine automation. Cares about compliance. Source of your pain! :) GREG: The guy who wants to consume innovation and new technology. Doesn’t fully understand C&A. My default position is that security is somone’s else’s job. FEN: I’m doing ops and I have to deal with people like Shawn and their inscrutable policies, and people like Greg who’s wants new functionality that adds vulnerabilities. To make things worse, 6 months ago I was introduced to FISMA and got saddled with this painful compliance process and checklists that gets in the way of doing real security. FEN: But two months ago, I discovered OpenSCAP and my perspective changed.
• #4: FEN: I can now harden and run security scans on new servers with a single ansible command. The security process is automated, does everything - and more - that I used to do manually. Not only do I satisfy compliance, I have greater confidence in the security of my servers. With about 100 lines of Ansible and Vagrant I can spin up and harden a server -- and provide attestation that it meets the compliance regs. (This ansible script displays the provisioning rvoles that add OpenSCAP and hardening to all machines and creates a “dashboard” for running the scans.)
• #5: Or, I can embed a single line of kickstart that will remediate my server to official baseline during the initial configuration. (( fade to Shawn ))
• #7: Planes were getting shot down faster than we could make them
• #8: SHAWN: Artisanally crafted war planes Custom parts Static build systems: One at a time. Waterfall. (( fade to Greg for FCC story )) GREG FCC STORY: In addition to the familiar artisanal/pet vs cattle story, there is a queueing problem Had a funded $200,000 project that was idled for months waiting for a server to get set according to policy - and conracts and budget made it impossible to use any of those funds to improve the primary constraint of configuring a baseline server and network.
• #9: You go through that entire process, and then someone wants polka dots. So you repeat the entire process. Plane still in official in “development”, but not “fielded”: NO MAINTENANCE Antiquated before gets to the warfighter
• #10: … and because no maintenance, they’d go back into the build system and then the security system and then gets in the way of everything else! Again, this is the queueing problem.
• #11: In January of 1940, America was being drawn into the growing war and our military was woefully unprepared. The Roosevelt administration asked Ford Motor Company to manufacture components for the B-24 Liberator bomber. Charles Sorensen, Vice-President of Production for Ford traveled to San Diego to observe Consolidated Aircraft's operations. He conceived to update the Willow Run bomber plant, eventually manufacturing 8,800 of these aircraft. Willow Run was the physical embodiment of the Ford Production system which was later transformed by Toyota into "Just In Time" and Lean manufacturing. This is where it all started. BTW, The book, Miracle at Willow Run is Sorenson’s autobiography -- and he never says why they wanted polkadots on the planes.
• #12: Willow Run was the physical embodiment of the Ford Production system which was later transformed by Toyota into "Just In Time" and Lean manufacturing. This is where it all started. BTW, The book, Miracle at Willow Run is Sorenson’s autobiography -- and he never says why they wanted polkadots on the planes.
• #13: First, break the plane's design into essential units and make a separate production layout for each unit. Next, build as many units as are required, then deliver each unit in its proper sequence to the assembly line to make one whole unit~ finished plane. Revamped production system. Now delivering one B52 per hour.
• #15: The two modes of building planes equates two
• #17: Elastic, Agile GARTNER
• #18: SHAWN: Do you think Google security accredits every server by hand? Do they spend months building the perfect system, or selecting the perfect vendor? No.They spend time on how they use the products: A/B testing, quick iterations, etc. The difference between a regular IT shop and the Googles of the world is the difference between a village cobbler and a tennis shoe factory. DevOps has been silod to Dev and Ops… what about security? (it’s been a tertiary, waterfall process) (( FADE TO GREG )) GREG: This is why we can’t accredit Mode 2 IT with the Mode 1 processes.
• #19: GREG: NIST Risk Management Framework literally defines a waterfall process for compliance determination.
• #20: Step 1: Categorize the system
• #21: Step 2. Select all the controls (e.g., define the requirements). Sometimes this is done for you, like FedRAMP or FISMA.
• #22: Step 3. Implement all the controls (e.g., develop)
• #23: Step 4. Assess the controls (e.g., QA after all requirements implemented) Configuration Management vs Security Attestation/Assessments Compliance (w/SCAP) is the ability to perform attestation at scale
• #24: Step 5: Authorize (e.g., deploy the accreditation) You can’t deploy without authorization. If you find out at authorization that you need polkadots, you have go back into the queue. Kg Or you get a waiver and fly knowing you have warped parts. And no matter the velocity of our CI pipeline, the authorization is still a one-off manual process.
• #25: Step 6. Finally continuously monitoring comes into play in classic mode 1 life cycle management. Fen: and devops goes… <click>
• #26: Fen...
• #27: GREG: But to be fair, it’s not like NIST, the authors of the RMF, didn’t anticipate this issue. They knew that automation would be essential to applying the catalog security controls widely.
• #28: So, after 5 years of work with MITRE, NIST releases the Security Content Automation Protocol, a suite of 8 easy to understand XML-based standards for expressing, testing, checklisting, tracking, and remediating security content.
• #29: GREG: Why SCAP anyway when we have idempotent infrastructure with CFEngine, Puppet, Chef, Ansible, etc? Because Security and Compliance are larger than the the Information System and its components. Security has been practices as tertiary manual process for an actual reason Because we have to connect tactical risk at the component level with organizational strategic risk management In fact, if you look at the 18 families of security controls in NIST 800-53 catalog of security controls, most are operational or management. Config tools silent about vulnerability And the Risk Management Framework is a whole organizational activity. The goal of SCAP is to aggregate vulnerability info to assess environmental risks
• #30: GREG: Why SCAP anyway when we have idempotent infrastructure with CFEngine, Puppet, Chef, Ansible, etc? Because Security and Compliance are larger than the the Information System and its components. Security has been practices as tertiary manual process for an actual reason Because we have to connect tactical risk at the component level with organizational strategic risk management In fact, if you look at the 18 families of security controls in NIST 800-53 catalog of security controls, most are operational or management. Config tools silent about vulnerability And the Risk Management Framework is a whole organizational activity. The goal of SCAP is to aggregate vulnerability info to assess environmental risks
• #31: SHAWN: Misperception that SCAP isn’t DevOps relevant, however: SCAP allows you to build a weather model: End point sensor monitoring Continuous Standardized data TURNING PRIMARY CONSTRAINT of C&A INTO AN OPEN SOURCE PROJECT The selection of security controls from NIST’s RMF is called a baseline Open sourcing primary constraint of baseline development NSA declassifies build DISA FSO, NIST Extend infrastructure as code to include security automation AND organizational attestation Where OpenSCAP exists, you can now integrate security into continuous delivery Tie organizational workflows with technical component delivery OpenSCAP reflects portfolio of tools + content
• #32: We get lost in the technical controls (password length, crypto algorithms) What we want is security policy and implementations to Security must scale across technologies, policies, and processes Trust and attestation scale differently than traffic and features Cultural differences Shared problem. We get lost in the technical controls (password length, crypto algorithms) Favorite scripts
• #33: It’s not just Red Hat. New apps and operating system (Drupal, Ubuntu and AWS Linux on the way) baselines are being added.
• #34: The code is CopyLeft - use and share.
• #35: ...And it’s being forked and extended to work in multiple environments.
• #36: A standard vulnerability scan produces a human readable report...
• #37: ...with detailed text describing the tests, links to the NIST Vulnerability Database (NVD), and even remediation scripts that can be employed to resolve the discovered issue.
• #38: Greg: I wanted condensed command line output so I created a “quick reports” filter on the scan results.
• #39: This shows an example run using Foreman.
• #40: It’s an open standard - it can do a lot now - and it can do even more as a F/OSS platform for encapsulating, communicating and providing attestations about known vulnerabilities in the systems you build.
• #41: We’d love to see you on the mailing lists.
• #42: Thanks.