Tag: NIST

  • Apple Outage Outrage | Linux Random Redo | Okta Hacked (or Not)

    Apple Outage Outrage | Linux Random Redo | Okta Hacked (or Not)

    Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

    This week: Why Apple services were down, Linux gets a huge RNG overhaul, and we wonder if Okta was hacked again. (more…)

  • Tackling Audit Compliance as Code

    Tackling Audit Compliance as Code

    Do the words, “It’s audit time!” make your stomach sink? If so, you’re not alone. Assisting with evidence collection for compliance audits around PCI DSS, SOC-2, ISO 27001, NIST and HITRUST is a drain on DevOps teams’ time and resources at companies of all types and sizes – time and resources that could be better spent driving innovation.

    The good news is, vendors have taken notice, and are delivering new tools and platforms that use automation to eliminate repetitive manual tasks and dramatically speed the audit process. This is entirely in line with the DevOps philosophy of tackling various IT tasks and requirements “as code” to remove tedium and improve efficiency and orchestration. In fact, as this movement to improve the compliance process picks up steam, I believe it’s entirely likely the next evolution is the use of open APIs and online communities where engineers can build and share software to automate a wide variety of evidence collection for compliance.

    But before we can get there, let’s understand where we are today and assess new opportunities going forward.

    Audit Support: DevOps’ Favorite Task

    As keepers of cloud environments, DevOps teams typically spend hundreds or thousands of hours each year gathering evidence for compliance audits. This tedious, manual labor takes significant time away from their primary job responsibilities. Large enterprises often have multiple, overlapping audits each year, with little break from the grind of evidence collection. Companies that make heavy use of the public cloud face additional challenges; the increased complexity means that evidence collection is more difficult, and the fast pace of software development and change management in the cloud (compared to more traditional monolithic application updates) makes it difficult for compliance to keep up. This contributes to an overall lack of clarity and confidence in the compliance process at the leadership level.

    Audit Prep as Code

    When I ran a cloud engineering team at a previous job, we realized the vast majority of repetitive, manual labor involved in evidence collection could be automated to save time and free up resources for other business needs. This automation also improved the completeness and accuracy of the evidence gathered, ensured that important areas weren’t overlooked and allowed for more regular assessment to prevent “drifting” out of compliance in the fast-paced cloud world. While automation helps with multiple aspects of compliance audits (such as evidence-to-control mapping and cross-walking evidence across common control frameworks), it’s the automation of evidence collection that primarily impacts DevOps.

    In this scenario, automated collectors crawl your public cloud environments and connected SaaS systems to rapidly gather technical evidence such as specifics on user access, encryption of data at rest, key management, network segmentation, firewalls, vulnerability scan reports and more. The results are transformed into formatted reports ready for internal review, analysis and auditor review/approval. This, alone, can save thousands of hours annually for typical enterprises facing multiple audits. Even better, the data is considered more complete and accurate from a compliance perspective, because it includes time stamps and other metadata to ensure capture and processing integrity.

    As mentioned, this is well aligned with the broader “X as code” mantra that underlies many DevOps automation initiatives – and why not? What could possibly be a more repetitive, manual task than capturing, renaming, organizing and describing screenshots?

    The Scripting Curse

    When confronted with evidence collection, an engineer’s first thought is usually, “I can write a script for that!” Scripting is a form of automation, but it has some limits in this scenario. First, scripting and doing the necessary QA shouldn’t be your day job; there are better things to spend time on. Second, given the explosion of cloud infrastructure and SaaS apps, there can be a lot of scripts to create. In fact, it’s arguably a never-ending task. Finally, while you understand your scripts, who’s doing the next audit? If it’s not you, are you going to explain and train someone else on all the work you’ve done? Scripting elements of evidence collection is an improvement over doing it manually, but is still only one piece of the larger puzzle.

    Compliance is a Community, not an Island

    So what’s the best way to automate evidence collection? Multiple vendors are tackling the challenge, from cloud platform providers to established GRC vendors and cloud compliance startups – and new tools have already begun to hit the market over the last few months.

    But as discussed, a primary challenge is that there is a lot of complexity in most cloud environments, and tools that approach the puzzle from only one direction – say, a particular cloud platform – still leave a lot of potentially relevant systems untouched. In fact, when you take all of the variations possible with cloud infrastructure into account, this might, ultimately, be a challenge that is best tackled at the DevOps community level.

    Consider this: adherence to industry standards for data handling, privacy and protection is not a competitive issue. We are all better off if everyone shares a basic commitment to complying with these IT security and compliance standards. Viewed from that perspective, the more we can lower the barriers to achieving this compliance, the broader the adoption will be.

    What I hope to see is a DevOps community that coalesces around automating audit readiness. At the engineering level, this could entail sharing of custom collectors. For platform and SaaS vendors, it means ensuring open APIs that allow capture and extraction of relevant data. And the compliance tool vendors must design their collection engines, evidence libraries and usage policies such that customization and sharing is possible. Similarly, automation tools must not only pull data from standard systems, but support pushing data from custom systems or legacy infrastructure. In my view, this bottoms-up approach is the best way to stop wasting DevOps’ time on audit prep, while still allowing enough autonomy to do what works best for their specific environment.

    In this future, then, perhaps an upcoming compliance audit won’t produce a collective groan from the DevOps team – or at least, generate a quieter one.

  • What is the NIST Cybersecurity Framework?

    What is the NIST Cybersecurity Framework?

    Cybersecurity threats are easier to handle when you have a framework to build off of. That’s why NIST developed the Cybersecurity Framework. Learn more.

    What You Need to Know About the NIST Cybersecurity Framework

    The National Institute of Standards and Technology, or NIST, helps organizations to better understand and manage their cybersecurity risks. NIST does this through its Cybersecurity Framework.

    The 5 Elements of the NIST Cybersecurity Framework

    There are five central elements of the NIST Cybersecurity Framework:

    1. Identify
    2. Protect
    3. Detect
    4. Respond
    5. Recover

    The 3 Components of the NIST Cybersecurity Framework

    In addition to the five main elements of the NIST Cybersecurity Framework, there are also three essential components.

    Framework Core: The Framework Core provides you with a set of activities to help you achieve specific cybersecurity outcomes. In order to help you achieve each activity, the Framework Core provides you with examples.

    Implementation Tiers: The Implementation Tiers provide you with an outline to increase the sophistication in your cybersecurity risk management.

    Framework Profiles: The Framework Profiles outline your cybersecurity activities and provides a look at the potential cybersecurity outcomes needed to meet your cybersecurity goals.

    How to Use the NIST Cybersecurity Framework

    In order to use the NIST Cybersecurity Framework, you must follow these three steps:

    1. Determine the appropriate implementation tier.
    2. Understand the gap between its current and target profiles.
    3. Put plans in place to implement the activities from the Framework Core to move toward the target profiles.

    The CIS Controls for NIST Cybersecurity Framework

    The Center for Internet Security (CIS) regularly publishes CIS Critical Security Controls that map to the NIST Cybersecurity Framework. While there are many sections to the CIS Controls, the most relevant is CIS Control 18, Application Software Security. The section recommends the following actions:

    1. Establish secure coding practices.
    2. Ensure software development personnel are trained in secure coding.
    3. Apply static and dynamic code analysis tools.

    To read more, please visit: https://www.perforce.com/blog/kw/nist-cybersecurity-static-analysis