Happy 36th anniversary to the day when a still unknown pirate took over 2 signals of Chicago television. On the night of November 22, 1987, the first incursion took over during the sports segment of the 9 o’clock news of WGN. The hijack lasted only about 20 seconds until they could wrest back control. The incursion only showed video and a loud buzz while a character that appeared to look like Max Headroom danced about.

Max was everywhere in the early 1980’s and was the definition of the future at the time. Max was seen on TV in the US on Cinemax and can count George RR Martin as one of the writers. Yes, Game of Thrones George RR Martin who celebrated Max week for the 30th anniversary in 2017.

Approximately 2 hours later, the character then took over the PBS affiliate WTTW during an episode of Dr. Who. This time there was sound but it was slightly intelligible. Below watch the clip with helpful subtitles.

Read more about the episode on Wikipedia.

The three key areas of the previous voluntary commitments included Safety, Security and Trust. In the realm of security, the commitment was plain in the fact stating that “Companies have a duty to build systems that put security first. That means safeguarding their models against cyber and insider threats and sharing best practices and standards to prevent misuse, reduce risks to society, and protect national security.” Cybersecurity is not undertaken by those in basements, but is front and center at the forefront of innovation. One might say, defense is finally having a voice after so many years of offense and a constant stream of data breaches.

How is the Order Laid Out?

This executive order is broken down into 13 sections with the bulk of the information coming in section 2 Policy and Principles and then further expounding on those 8 policies from section 4 through section 11. The 8 key policies are as follows:

1. Ensuring the Safety and Security of AI Technology

2. Promoting Innovation and Competition

3. Supporting Workers

4. Advancing Equity and Civil Rights

5. Protecting Consumers, Patients, Passengers, and Students

6. Protecting Privacy

7. Advancing Federal Government Use of AI

8. Strengthening American Leadership Abroad

After laying out the individual overarching policy, each of these major sections sets out in total 84 proclamations ranging from 30 to primarily 540 days from the date of the order.

What does it say about cybersecurity?

Policy wise, the order lumps safety and security together in the first policy. Whereas the first voluntary standards were more explicit, the policy addresses “ biotechnology, cybersecurity, critical infrastructure, and other national security dangers” in a single sentence. Furthermore, it speaks to testing, evaluation and monitoring as opposed to the much stronger language earlier whereby they proclaimed that “Companies have a duty to build systems that put security first”. Given the nature of this document though, the details are yet to be established.

The heart of the order comes in Sec. 4.1: Developing Guidelines, Standards, and Best Practices for AI Safety and Security. In this section, the EO puts the National Institute of Standards and Technology (NIST) in charge within 270 days of establishing guidelines, best practices, for a number of areas including red-teaming! Additionally, the Department of Energy is singled out to develop defensive measures to guard against “nuclear, nonproliferation, biological, chemical, critical infrastructure, and energy-security threats or hazards”. One of the key takeaways over and over again, in this section and others is the reliance on testing as a key safeguard. As we’ve touched on before, Security is Part of Quality. Testing AI is the only way to address “AI systems’ most pressing security risks…while navigating AI’s opacity and complexity”.

In Sec. 4.2, and in keeping with previous executive orders, IaaS providers will be required to report to the Secretary of Commerce “when a foreign person transacts with that United States IaaS Provider to train a large AI model with potential capabilities that could be used in malicious cyber-enabled activity (a “training run”)”. It also requires the determination of “set of technical conditions for a large AI model to have potential capabilities that could be used in malicious cyber-enabled activity” and otherwise establishes them in the meantime.

Section 4.3 specifically focuses on “Managing AI in Critical Infrastructure and in Cybersecurity” and starts to really deep dive into protections. The first focus is for the DHS and CISA to develop assessments related to how “deploying AI may make critical infrastructure systems more vulnerable to critical failures, physical attacks, and cyber attacks, and shall consider ways to mitigate these vulnerabilities”. It also directs the Secretary of the Treasury to develop an assessment specifically for financial institutions. Furthermore it directs the Secretary of Homeland Security to develop an “Artificial Intelligence Safety and Security Board as an advisory committee” consisting of government, academia and private sector members.

4.3(b) is the most exciting yet as it directs both the Department of Defense and the DHS to “each develop plans for, conduct, and complete an operational pilot project to identify, develop, test, evaluate, and deploy AI capabilities, such as large-language models, to aid in the discovery and remediation of vulnerabilities in critical United States Government software, systems, and networks.” To say I’m excited that they put defense forward specifically, when for decades cyber has almost exclusively meant offense, would be an understatement.

4.4 ventures into the risks posed by Chemical, Biological, Radiological and Nuclear (CBRN) threats. They call out specifically the threat related to biological weapons. Luckily Politico deep dives into this threat in their attention grabbing headline “The Mad Scientists of AI”.

via Ripjaw56

Congratulations, you’ve got in hand your first SOC 2 report, so SOC 2 is done right? Let’s not underestimate the wisdom of Daft Punk when they say, “More than ever, hour after hour, Work is never over” as this is not the finish line for your company and SOC 2. It’s just the first lap of many in the SOC 2 marathon, as we focus on continuous security and compliance.

My name is Daniel Tobin, and I’ve been working at the intersection of DevOps, Security, and IT for the past 20 years and have been the first or only Security hire for each of my companies. Of those 20 years, I’ve been leading SOC 2 efforts for over 10 years and I can tell you, that I have over 10 different experiences of audits, even within the same audit firm and company. I can also tell you that I’ve probably had to explain nearly every year that SOC 2 is never over, we’re already in the next audit period.

A more cynical version of myself would refer to the myth of Sisyphus, pushing the rock of compliance up a hill only to start over every year when I think of all the checklists and matrices on our journey to that next waypoint. Yet, as Daft Punk correctly points out, it is not about pointless labor but continuous improvement. Instead the focus should be on making the company better and stronger year after year. Compliance does not need to be a test of meaningless work. Instead, compliance should be viewed in the light of continuous improvement and habit-building. It is wise to set out each new day by tackling the most difficult thing first; with that challenge out of the way, the rest of the day will be a breeze, right? Right?

Now that it’s morning again after your audit and we can start anew, let’s return to the beginning of Daft Punk’s wise words: “Work it harder, make it better, Do it faster, makes us stronger.” To make the entire process of addressing compliance better and faster, make it a priority to partner with an automated compliance solution for continuous security and compliance. The new class of automated compliance solutions like SecureFrame, Vanta, Drata, etc., have not only made audits easier for everyone, they have greatly simplified and standardized best practices. These solutions offer continuous assurance instead of haphazardly relying on point-in-time screenshots. This automation takes the guesswork out of compliance and provides continuous security monitoring. With automation in place, we can move faster and instead focus on critical features for the platform we’ll be rolling out and in-depth security-focused projects.

So with all this talk about good habits, racing, Greek myth, and Daft Punk, what is SOC 2? Why does anyone care about it? For that, we look to the AICPA, the standards organization responsible for developing SOC 2: 

SOC 2 reports are intended to meet the needs of a broad range of users that need detailed information and assurance about the controls at a service organization relevant to security, availability, and processing integrity of the systems the service organization uses to process users’ data and the confidentiality and privacy of the information processed by these systems. (1)

In essence, the AICPA created a framework to be applied across various parts of an organization and developed controls for companies to follow to attest that they have assurances for the security and overall integrity of their systems. SOC 2 has become the gold standard for companies in the US to ensure that the companies they are working with have a baseline of assurances when entrusting each other with valuable and sensitive data. In Europe, ISO 27001 is the gold standard for companies instead of SOC 2. At your company, you should weigh where your customers and their data is and the business needs of also obtaining ISO 27001. ISO 27001 is generally considered the more technical of the two, but it does have minimums of audit time based on company size.

Now that your company has gone through the SOC 2 process, does that mean anyone who signs up for your service, no matter the service, will also automatically receive SOC 2? I’m sorry, but that’s not how it works. Working with vendors who have SOC 2 can speed up your due diligence and remove the need for filling out custom security questionnaires, but you would still need to go through the process yourself to obtain your own SOC 2. Numerous SOC 2 controls are unrelated to technical components and are more about your company policies. For example, a key element is vendor management and organizational controls like hiring and employee and CEO performance.

As Graduation Kanye says “Now that, that don't kill me, Can only make me stronger”, SOC 2, when used as part of a larger security strategy and especially with todays automated security tools can make your company more secure. Even as your company is telling you “I need you to hurry up now, 'Cause I can't wait much longer”, remind yourself and them of the overall process. This audit might be done, but SOC 2 is never over.

2020 was a year that lasted, if not close to a decade, then long enough that we’ve lost track of how long it’s been. We don’t think anyone could have predicted what 2020 would look like in January but we’re almost done with it. Despite all of the negative things that have transpired, there has been innovation in the security as code space. IT leadership and security vendors are increasingly taking their message directly to developers, empowering them directly to test, find and fix issues even before these issues can make it to dedicated security teams. We, for one, are overjoyed at this, as we also believe that integrating directly into CI / CD and developer workflows is how we start to make security truly effective.

What follows is our lucky 7 list of favorite Security as Code tools—tools that have seen strong adoption in the companies we work with—plus one bonus tool we’re really optimistic about. They  range from major CNCF / open source projects to commercial offerings, and they cover everything from Policy as Code to innovative infrastructure testing to automated dynamic application testing and even a major foray into Zero Trust. 

So, in no particular order, here is a proposed list of Security of Code tools that your team should consider using in 2021:

• Open Policy Agent (OPA) by Styra

  • This policy as code framework debuted in late 2016, joined the CNCF in early 2018, and showed Styra to be a leading innovator in this space. Today, this CNCF project is waiting on a final count to confirm that it will be moving to a CNCF Graduated project at any point now; the votes are still trickling in. 

  • The OPA project also grew by adding the awesome project Conftest to their portfolio of CNCF policy as code offerings. Conftest can integrate directly into your CI/CD pipeline, bringing robust testing to your configuration as code.

  • Why we like it: It’s plug-and-play, with a standard policy engine that integrates with your existing tools or ones you are building yourself. 

• Checkov by Bridgecrew

  • Checkov is a Python-based infrastructure as code scanning open source project announced by Bridgecrew in the before times of January 2020. From the beginning, Checkov was designed to run pre-commit and as part of your CI / CD pipeline. 

  • Checkov now supports 150+ out of the box scan configurations and can scan everything from Helm to Terraform to Cloudformation to even serverless and more. 

  • Why we like it: Out-of-the box templates for infrastructure scanning

• Hashicorp Sentinel

  • Hashicorp’s Sentinel is the grand-daddy of tools listed here, having been first announced in 2017, about 6 months before OPA’s acceptance as a CNCF sandbox project. Sentinel provides policy as code so that anytime an organization deploys to the cloud, the deployment adheres to their security rules.

  • Hashicorp Sentinel still exists as only an add-on for Hashicorp’s enterprise offering, but it’s a must if you’re already on the enterprise edition.

  • Why we like it: They’ve had this for over 3 years and yet are still one of the few true frameworks in the security-as-code space.

• Stackhawk

  • Led by Joni Klippert, Stackhawk offers a test-driven method of security for DevOps teams—tackling the problem of using antiqued methods of security testing that often leave modern day applications vulnerable and exposed to risk too late in the production cycle. 

  • Not to mention, this female-founded, Denver-based company closed a $10M Series A funding round in October. 

  • Why we like it: They’re now offering a free developer plan to get started.

• Semgrep by r2c

  • For many, running static analysis has become expensive, CPU intensive and cumbersome to say the least. r2c recognized this and decided to offer an alternative: a lightweight, offline tool that allows you to squash classes of bugs with powerful, precise rules putting developers in control. 

  • r2c raised a Series A in late October and brought on Clint Gibler  of tl;dr sec fame to raise awareness of their project. TL;DR, check out Semgrep today if you haven’t already.

  • Why we like it: A lightweight static analysis tool that allows us to utilize the power of grep 

• Snyk

  • Following a ton of major product innovations and two massive fundraising rounds in 2020 into Series D, we don’t think Snyk is sneaking up on anyone anymore. 

  • With its ability to scan code, containers, and deployment frameworks for vulnerabilities, Snyk has established itself across the entire pipeline from open source to license management to infrastructure code scanning to containers and more. Their tools now empower 1.5 million developers to build and deploy code and infrastructure securely.

  • Why we like it: With its infrastructure-as-code scanning feature this year, Snyk can now can be utilized across the pipeline

• GitHub’s Dependabot

  • Dependabot began as a standalone project and joined GitHub at the beginning of 2019 and immediately helped thousands automatically keep their dependencies up to date. 

  • In June, GitHub announced the latest Dependabot features, enabling not just security updates, but complete package updates for both security and regular updates. Dependabot comes free with your usage of GitHub, so if you’re already there, turn it on and automate your dependency management in 2021, if you haven’t already.

  • Why we like it: It’s GitHub – c’mon!

• Hashicorp Boundary

  • Our bonus tool for 2021, Boundary was only announced in October this year. If ever there was a year to announce a VPN-free remote access solution, this year was the year to do it. 

  • 2020 brought us the double whammy of everyone working remote and multiple high profile VPN products being pwned. Remote, mobile workforces require exciting, innovative solutions and we expect nothing less than that from Hashicorp.

  • Why we’re optimistic: This is a great step forward for zero trust architecture!

We hope that you have a great 2021, full of many terrific releases, fewer bugs, and no security incidents!

• Are you using Chrome with an angry red update button in the corner? Do so ASAP as this contains patches from the zero days demonstrated at Tianfu Cup mentioned in TSD-83. Read more at Security Week.

• A novel theoretical attack on compliers using unicode, Trojan Source, has been published by researchers at the University of Cambridge. The researchers searched public open source projects and have found no compromises yet, but with their publication and lack of universal patches, we may see exploits soon. Read more at KrebsOnSecurity

• The NRA is the latest victim of Grief ransomware. Grief, thought to be mostly just a rebrand of Evil Corp, posted about the NRA on their leak site and eventually The NRA responded. Read more at ZDNet

• Motherboard delves into the booming business of 2FA bots, now that 2FA is becoming integrated into many apps and websites. Always keep an eye out for these scams.

• And finally Motherboard has published research about a company that sells location data that still received data even after users opted out of the collection.

Owl fun and facts:

New research from a team in Israel has concluded that barn owls have “place cells” like humans allowing them to make mental maps and possibly aid in flying.

Place cells are known to exist not only in humans, but also other mammals like rodents and bats. They have also been detected in tufted titmice as they walk.

However, this is the first time that evidence for place cells — which fire at a high rate when an animal visits a particular location — has ever been seen in birds in flight.

Read more at The Daily Mail or The New Scientist

A Shout Out:

Christian Frichot has released hcltm, an open source project that uses HashiCorp’s HCL. Love to see this as an extension of security and policy as code using a common language that your DevOps and AppSec teams are probably already using. Add in HCL parsing from Semgrep as suggested by Daniel Bilar and we have a complete ecosystem for creating and parsing threat models. As for the future, “TF asset consumption is on the roadmap.” h/t to TLDRsec

• An FTC report on advertising by ISPs shows that many are harvesting vast amounts of data. The report is simply that and no rules are proposed at this time to limit this data harvesting. Read more at Motherboard

• A multi country effort took down the infrastructure for the REvil ransomware gang according to officials and the admin. Read more at Reuters

• First they came for our gas and then they came for our meat processing plants and now ransomware operators have come for a manufacturer of candy corn? Regardless of what you think of candy corn, I hope we can all agree this has gone too far. Thankfully they’re back at near capacity. Read more at Gizmodo

• Ransomware group FIN7 setup a fake security company to hire security researchers to ultimately use them in ransomware attacks according to research from Gemini Advisory and Microsoft. Read more at The Record

• CISA is warning about a bug in a GPS library could switch some dates back to 2002 if not updated. Read more at The Record

• Microsoft is warning that the Russian based attackers that targeted SolarWinds have infiltrated at least 14 IT supply chain firms since May. Read more at BleepingComputer

• The Department of Commerce announced new controls that would target the export of hacking tools without license to certain countries. There is some concern about legitimate prevention of research but overall, many have found there is quite a bit of nuance to it to strike the right balance. Read more at The Washington Post

• The truth about Truth Social is that it’s just using a fork of Mastodon and has little in the way of preventing random people creating donaldtrump and mikepence user names before it is even officially launched. The maintainer of Mastodon is examining whether hiding their use of Mastodon violates the license. Read more at Motherboard.

Owl fun and facts:

Shelley’s Eagle Owl has been seen and photographed for the first time in 150 years! “There have been occasional reports over recent decades from people believing they have heard or briefly seen Shelley’s Eagle Owl from a few different localities across West and Central Africa from Liberia to Angola…The pair only saw the bird perched for 10-15 seconds but in that time managed to take photographs that confirm the identification due to its distinctive black eyes, yellow bill, and huge size, which in combination rule out all other African forest owls.” Read more at The Imperial College of London.

A Shout Out:

Endpoint visibility tool osquery has recently released 5.0 with major improvements including “an EndpointSecurity-based process events table for macOS”. Security firm Trail of Bits has been instrumental in contributing to osquery and has a full rundown of everything in the new version which you can read on the Trail of Bits blog.

• KrebsOnSecurity looks into the methods thieves used to steal one time passwords and gain access to Coinbase accounts

• Reporters in Missouri discovered a website with Social Security Numbers in the HTML source code and now the Governor is threatening to prosecute the “hackers”. I really hope this settles down, but he seems to just be ratcheting things up. Read more at KrebsOnSecurity

• At Tianfu Cup, China’s Pwn2Own equivalent, researchers demonstrated zero days for Windows 10, Ubuntu, iOS 15, Chrome and more. Read more at The Record

• Ransomware payments from the first half of the year exceeded all of 2020’s payments according to the Treasury Department financial crimes unit. Coindesk has the full story

• Ransomware knocked off Sinclair Broadcasting Sunday morning interrupting the broadcast of NFL games, morning news shows and more. Read more at The Record

• A group of security research luminaries gathered together to write a 46 page document skewering Apple’s CSAM scanning technology. Ross Anderson provides a good overview and you can download the full paper, Bugs in our Pockets: The Risks of Client-Side Scanning from Arxiv. The full list of authors is Hal Abelson, Ross Anderson, Steven M. Bellovin, Josh Benaloh, Matt Blaze, Jon Callas, Whitfield Diffie, Susan Landau, Peter G. Neumann, Ronald L. Rivest, Jeffrey I. Schiller, Bruce Schneier, Vanessa Teague and Carmela Troncoso.

• Acer has had a bad week getting hit twice by the same threat actor. Read more at BleepingComputer.

• The Buffalo News is reporting that the total cost to respond to and beef up security after a ransomware attack at Buffalo Public Schools will total $10 million.

• Finally, the FBI has warned about fake sites posing as sites offering unemployment benefits. Keep an eye out and be ever vigilant. Read more at Bleeping Computer

Owl fun and facts:

Bay Nature Magazine has just published a story about Humboldt State researchers on the use of owls as natural predators for Napa Valley vintners. As of January, a key rodentcide had been banned in California for the affects it had on upper predatory animals like owls. The research will both monitor their effectiveness at taming the rodent population and keep an eye on the owls as well.

A Shout Out:

RBAC Tool from Rapid 7 “simplifies querying and creation of RBAC policies.” This is an open source suite of tools ranging from visualization to analysis and highlighting risky permissions to generating roles and more.

• The entirety of Twitch was leaked including source code and payouts from 2019 to their streamers. If you have a Twitch account, make sure you enable two-factor authentication ASAP. The leak was first reported by Video Games Chronicle. Twitch later said a misconfigured server was responsible for the massive breach according to ZDNet

• More details are out on what information the Solar Winds hackers had access to including “information about counter-intelligence investigations, policy on sanctioning Russian individuals and the country’s response to COVID-19” via Reuters

• In a new secure by default step, Google is going to turn on two-factor on 150 million accounts by the end of the year via The Verge

• It’s Patch Tuesday with Microsoft patching over 70 flaws in this update. Update ASAP. Read on for the full list at KrebsOnSecurity

• Microsoft has also released a tool for properly securing Windows 11 machines. Read more at BleepingComputer

• BrewDog, the Scottish brewery known for their crowd funding model and high ABV beers, inadvertently exposed data via API for their Equity Punks for 18 months via BleepingComputer

Owl fun and facts:

Flammulated owls are tiny and often heard more than seen, but if you’re in the Colorado Springs area, check out Manitou Experimental Forest to potentially get a view of this tiny owl. Read more about this wonderful little owl at Pikes Peak Courier

A Shout Out:

Last Week in AWS has released their 2021 Charity T-Shirt benefitting 826 National.

• A company that handles billions of text messages reported to the SEC that it was hacked and the attackers had access for years. The hack began in May 2016 but they did not notice until May 2021. Read more of the report at Motherboard.

• It’s Cybersecurity Awareness Month, now in its 18th year! The evergreen theme is “Do your part. #BeCyberSmart” and is the theme for this week. CISA has released a number of tip sheets including Cyber Secure at Work, Safe Travel, Multi-Factor Authentication (MFA), Online Privacy, Protecting Your Digital Home, Creating Passwords and Social Media Cybersecurity. You can also check out the proclamation from the President on Whitehouse.gov

• In what is billed as “the largest investigation in journalism history”, The Pandora Papers is the most expansive leak of tax haven files.

• Hackers were able to bypass MFA in Coinbase and steal funds from 6000 users. Read more at The Record

• A hacker leaked data to The Intercept revealing various partisan issues related to COVID-19.

• If you’re running Apache, check your version as there is a zero day vulnerability that could expose sensitive information. Read more at BleepingComputer

• Android rolled out their October update with 41 fixes including 3 critical. Update ASAP! Read more at BleepingComputer

• President Biden announced a 30 country coalition to fight against ransomware late last week. Read more at BleepingComputer

• And finally, Facebook, Instagram and WhatsApp all went down to an internal faulty configuration change and were not hacked as some initial rumors said. KrebsOnSecurity has a good overview of the information known about the change to BGP. In the meantime, a Twitter user caught the scene outside of Facebook HQ.

Owl fun and facts:

Yahoo has a fun article about why owls are a symbol of Halloween according to folklorists.

A Shout Out:

Phrack is back! The legendary zine has published their first issue in 5 years. Phrack was first published in 1985. Check out Phrack Issue 70.

We are excited to see this as a major first step at setting forth standards for not only government agencies but those that will be under close scrutiny such as the utility industry. Specifically we’ll talk more about the items in the order that relate to accelerating migration to Cloud Security as well as highlight some of the other notable items called out in the order. 

As we have seen recently with the Solar Winds hack and the Colonial Pipeline ransomware event, these broad standards are needed across the board for much of the federal government and for vital, vulnerable sectors of industry and infrastructure. 

How is the Order Laid Out?

The executive order is broken down into 9 sections, each covering a key area of improvements in cybersecurity operations. The first section sets the tone: the policy of the administration is “that the prevention, detection, assessment, and remediation of cyber incidents is a top priority and essential to national and economic security.”

The 9 sections cover the following:

1. Overall policy of the government

2. Sharing threat information 

3. Zero Trust Architecture and cloud usage

4. Declares 2021 Year of the #SBOM

5. Establishes a Cyber Safety Review Board

6. Seeks to standardize incident response (IR) practices across all agencies

7. Specifies a centralized SOC, Endpoint Detection & Response, and threat hunting

8. Improving logging for investigations and remediation

9. Ensures that systems operating in the sphere of national security meet or exceed the standards outlined

The order will apply to over 100 agencies that are under the purview of the Cybersecurity and Infrastructure Security Agency (CISA) and includes a number of deadlines ranging from 14 days to 360 days from the issuance of the order. All in all, the executive order speaks generally in broad strokes but ones that have been needed for quite some time.

The sections cover major initiatives and for some the broadness of them may upset those pushing for faster turnaround times in response to the string of high profile breaches like some of those mentioned earlier. For many of these directives though, the measures called for would be difficult to implement, even for much smaller organizations, given the timelines put forth.

Let’s dive into some of the highlights:

Migration to the Cloud:
What Does it Say About Zero Trust Architecture and Cloud Data Security?

As it relates to Cloud Security, Section 3 is by far the most important and exciting to us:

The Federal Government must adopt security best practices; advance toward Zero Trust Architecture; accelerate movement to secure cloud services, including Software as a Service (SaaS), Infrastructure as a Service (IaaS), and Platform as a Service (PaaS); centralize and streamline access to cybersecurity data to drive analytics for identifying and managing cybersecurity risks; and invest in both technology and personnel to match these modernization goals.

The heavy lifting for this section has already been performed by NIST and their publication of Special Publication (SP) 800-207, Zero Trust Architecture. But as the paper points out, progress has been modest: despite the roots of Zero Trust being pushed as a concept since before 2004, and despite leaders spending over a decade urging agencies to move to the architecture, few agencies have implemented it. 

At Cyral, we support these building blocks and built our company to help solve one of the biggest problems here which is specifically on cloud data security and governance. Our focus from the beginning has been on enabling Zero Trust Architecture to secure and protect the data cloud. We wholeheartedly believe that Zero Trust Architecture for SaaS, IaaS, and PaaS, coupled with Security as Code (SaC), is the way forward.

The key directives of this section then go on to mandate that each of the agencies must provide reports on how they are meeting key objectives including: 

• Migration to cloud services

• Uniform cloud standards and architecture

• How those plans relate to the implementation of Zero Trust Architecture

• Data classification  

• Requiring agencies to adopt MFA and encryption for data at rest and in transit within 180 days

We are incredibly excited to see all of these laid out as objectives and key results and look forward to seeing progress on these important goals. And personally, as someone that has lead, managed and implemented such projects before, each of these by themselves can be a massive undertaking depending on resources available and their starting point. A number of these directives can be complementary and the language at times does focus more on assessment of the situation than implementation yet, I still expect that this will be a hectic time for those on the ground.  

Other Important Sections from the Executive Order

Beyond the key focus on cloud security and zero trust, there are several other sections that are of great interest that we’d like to highlight including: 

2021: Year of the SBOM

Software Bill of Materials (SBOM) has been bubbling around for awhile, and this is the year that it finally seems to be going mainstream thanks to the work of people like Allan Friedman at the National Telecommunications and Information Administration (NTIA). Allan spoke at BSidesSF in 2020 about SBOM as part of the push for all companies to at least start thinking about this problem. 

SBOM in this order  specifically relates to the focus on software supply chain security. Supply chain attacks seemed only theoretical and something that was going to happen in the future and we are now all living in the future with SolarWinds, Dependency Confusion and Codecov all coming out in the past 6 months! Further portions attempt to develop a certification for secure software, and even lays out multiple explicit safeguards that companies should follow. These steps range from SAST / DAST to code signing to administratively separate build environments to vulnerability disclosure, encryption and more. 

Consumer labeling for IoT Devices

Another exciting portion of this section is a consumer labeling program “to educate the public on the security capabilities of Internet-of-Things (IoT) devices and software development practices.” Think of the labeling similar to “energy star” labeling where it indicates whether software has followed specific security guidelines. With work from home here to stay and the proliferation of IoT devices with questionable security, this will hopefully encourage manufacturers to take security of their devices more seriously.

Establish a Cybersecurity Safety Review Board

For any event deemed necessary to create one, a review board with private companies as well representatives from the DoD, DoJ, CISA, NSA and FBI will be convened. The first such board will be related to the SolarWinds event and will be responsible for recommendations within 90 days of creation. The board will be required to develop an initial review within 30 days and their expectations going forward. The board is extended automatically every 2 years unless the President deems otherwise as it is an extension of the Homeland Security Act of 2002 which established the idea of advisory committees. As with much of this order, this codifies a great deal of disparate existing policy and procedures and explicitly provides authority and urgency to act on it. Do you think they’ll run a blameless post mortem? Perhaps if it’s an international incident they can run a Five Eyes Five Whys.

Standardize an Incident Response (IR) Playbook

This is another section creating uniformity among the many various standards, policies and procedures already in place, this one specifically relying on NIST standards. NIST published the Guide for Cybersecurity Event Recovery in late 2016 with likely varied uptake across federal agencies. CISA will have final say on all IR procedures ensuring that for every event that the procedures were followed correctly.

Endpoint Detection & Response (EDR) and Centralized SOC

EDR and threat hunting makes their way into the spotlight with a requirement of all agencies and even National Security agencies to implement a unified EDR solution. This will also require the heads of agencies and National Security to cooperate as well. For the civilian agencies, the data should be available to CISA, while the national security agencies will be required to produce a report on whether or not it should be centralized.

This directive will allow for a centralized visibility eliminating potential siloes across agencies. By having a centralized view, CISA will be able to spot trends and threats and detect operations like the Solar Winds breach sooner. This centralized monitoring will allow for a single pane of glass for CISA to gain unified visibility into all activity and bubble up issues sooner than later.

One of the major players in the EDR space, Tanium already advertises that they have five branches of the US military on their platform which should help with at least a portion of this order. This section continues the unification theme that has been continuous throughout the order as the government tries to execute security at scale against advanced persistent threats (APTs).

Log Everything with Assurance

The last major portion focuses on best practices around logging and assurance of those logs. With advanced threats already having gone deep into government networks, having assurance that the logs be immutable is paramount to ensure that the hunting will actually find threats. Logs without a guarantee of immutability, cannot be trusted when the threat actor has the capabilities to modify them. Additionally, having proper logging speeds-up forensics and reduces mean time to resolution. Standards around retention and quality of logs will need to be established and applied across all agencies for both on premise and cloud workloads as well as IT providers. Logs are core to Cyral’s implementation of data activity monitoring so we can only applaud that there will be standards implemented for any of those that are not there yet.

Conclusion

President Biden’s Executive Order on Improving the Nation’s Cybersecurity is a big, bold move aimed at standardizing and socializing the best practices that have been developed individually at multiple different agencies and levels. Zero Trust Architecture, cloud migrations, SBOM and EDR have all been advocated among those pushing the needle on security. This executive order though, puts the full weight of the federal government behind these initiatives that will hopefully move all of us forward. We have seen the devastating consequences and near daily leak of personal, private, R&D and interruption of our daily lives on systems that have remained insecure for too long. This executive order, when fully implemented, will hopefully stem the tide of attacks and crimeware that has overwhelmed our IT and OT infrastructure.

From startups to large organizations, handbook-based policy management rarely scales well and is often applied in a non-uniform way. Policy as Code addresses this by codifying policies, providing visibility, and enforcing them automatically. By adopting Policy as Code, an organization forces itself to translate its policy decisions into code that enforces decisions in the same way, every time.

Under Policy as Code, policies are standardized into records readable by both the people who manage them and the systems that enforce them. Policies written in formats like YAML and JSON allow this, because they’re consistent enough for an authorization system to enforce and simple enough for security personnel to read.

With machine-readable policies, authorization can be offloaded to security software, reducing the toil necessary to constantly monitor and maintain one-off requests, freeing development teams to focus on core features. 

With policies stored consistently and globally, realtime auditing of access grants is possible for the first time. Security teams can monitor and review authorization decisions and policy changes, allowing the entire company to move faster without breaking core security and compliance requirements.

Benefits of Policy as Code

Policy as Code reduces toil for IT and security teams by helping to automate workflows that are typically done manually.

1. Simplify Onboarding/Offboarding
   You simplify onboarding of new employees, removal of access for departed employees, and rollout of new tools and technology.

2. Gain Full Tracking/History
   You no longer need to traverse different systems to track down the full policy documentation that may have been stored in your standard tracking system and in other communication systems. Full tracking and history is now visible instantly in the organization’s version control system, where the responsible teams can view every policy and permission change.

3. Improve Approval Process
   You reduce the toil of approving and denying requests. By codifying your decisions, those who grant access no longer need to perform the legwork to determine if someone should get access or not. Permissions can be auto-provisioned at exactly the level each user or group needs, and no more.

4. Eliminate Guesswork for Role-Based Access
   Policy as Code takes the guesswork out of granting permissions and applies your policies uniformly across every request, from any application, tool, or user. Once Policy as Code is integrated with your organization’s directory service and groups, it becomes possible for the security and IT team to implement true role-based access.

5. Reduce Uncertainty
   Policy as Code gives managers and employees a clear view of access privileges throughout the organization, and reduces uncertainty. Permissions can be reviewed by the right people, anywhere in the organization. When a change is needed, the request can be submitted and reviewed in a standard, well-tracked way. 

6. Allow for Self-Service Options
   Optionally, employees can self-serve some permissions requests thanks to automatic policies that evaluate the user’s role, their group affiliations, and the sensitivity of the resource being requested. Whether changes are streamlined or self-serve, employees appreciate autonomy and transparency because it cuts the confusion about how or when their request will be reviewed. 

7. Gain Real-time Audit Logs for Compliance
   Finally, by clearly tracking all permissions changes, an organization has a real time audit log that reduces the work needed to prepare for compliance and certification reviews. With a clearly defined system of record for security policies, approvals are tracked automatically, and there’s no longer a need to search multiple systems to get a full picture of access rights.

As you can see, the benefits of Policy as Code can have a big impact on reducing manual work, and improving processes in a variety of ways. Let’s dig in more into how this is put into practice and we’ll take a look at a few examples of how to create policies and provision or deprovision access. 

Examples of Policy as Code

Access Provisioning

Usually, when a new developer, say Frank Hardy (username fhardy), joins the organization, a JIRA ticket like the one below will show up in the inbox of an IT/DevOps admin:

Even at this beginning stage, many things can go wrong, starting with the ticket itself being filed against the wrong person or team, or as is often the case, not having enough information, leading to a tedious back-and-forth between requester and administrator.

On the other hand, using an Access Management as Code framework, the developer’s manager just submits a pull request in a version control system such as GitHub with details as shown in this example:

Requests now can follow the standard checks defined in your version control system, including limits on who can change what (“protected branches”) and required approvals. This ensures that each request—like our onboarding request—always goes to the admin in charge.

Along with GitHub access, let’s say fhardy’s job function requires access to the staging MySQL database as well. The following Terraform code accomplishes this by creating a user called fhardy and assigning it to a developer role.

resource "mysql_user" "fhardy" {
 user               = "fhardy"
 host               = "staging-mysql.platform.acme.com"
 auth_plugin        = "AWSAuthenticationPlugin"
}
resource "mysql_role" "developer" {
 name = "developer"
}
resource "mysql_grant" "developer" {
 user     = "${mysql_user.fhardy.user}"
 host     = "${mysql_user.fhardy.host}"
 database = "app"
 roles    = ["${mysql_role.developer.name}"]
}

Creating Policies

Continuing with our example, the next step in the Access Management as Code journey is to make sure privileges for the user fhardy are set up correctly. This can be automated in a number of ways, depending on your environment. In the example below, we’ll show how it would be done using Styra’s Open Policy Agent (OPA), a policy framework that integrates well with popular cloud stacks. OPA helps to decouple policy from the service itself. OPA policies are written in Rego, a language that allows for declarative, fine-grained control.

For example, you could use OPA with a built in-house internal CMS tool to govern developer access to an organization’s customer data repository. The following OPA code shows how to only allow the members of the CMSAdmin group to see customer contracts.

package httpapi.authz

import input

# Allow CMS admin members access to customer contracts.
default allow = false
allow {
  input.method == "GET"
  some contractId
  input.path = ["contracts", contractId]
  input.user == cmsAdmins[_]
}

# Only the following belong to the CMS admins group
cmsAdmins = ["ndrew", "mwang", "fhardy"]

Once the above validation is implemented using OPA, only members of the CMSAdmin group can see customer contracts in the CMS tool.

Example: Access Deprovisioning

Using Terraform, deprovisioning is as simple as deleting the relevant lines of code from the terraform script and generating a pull request. Once the pull request is peer reviewed and merged, running terraform apply would automatically revoke access.

Below is an example of revoking fhardy’s access to the organization’s GitHub account.

Summary

Using manual processes and reviews for policy enforcement can take a toil and leave your organization at risk. Policy as code can unify and automate your policies while providing you with greater visibility for auditing and compliance. This approach extends on infrastructure as code, which brought similar benefits.

Below is a white paper I wrote while Security Lead for Cyral.

Overview

Security as Code is the methodology of codifying security and policy decisions and socializing them with other teams. Security testing and scans are implemented into your CI/CD pipeline to automatically and continuously detect vulnerabilities and security bugs. Access policy decisions are codified into source code allowing everyone across the organization to see exactly who has access to what resources. Adopting Security as Code tightly couples application development with security management, while simultaneously allowing your developers to focus on core features and functionality, and simplifying configuration and authorization management for security teams. This improves collaboration between Development and Security teams and helps nurture a culture of security across the organization.

Implementing Security as Code

Security as Code generally comes in three different forms: security testing, vulnerability scanning and access policies. Each of these enable your Engineering teams to understand and fix security issues early on in development as opposed to waiting until the project is ready to ship and is blocked due to security concerns. When you take on a Security as Code mentality, you are codifying collaboration directly where your development teams are working. Security as code lifts up Development and Security teams together to allow each to focus on their core strengths.

Security testing expands on best in class coding practices to add to the standard suite of tests to not only include functional and integration testing but also security focused testing. Static analysis for security vulnerabilities can be implemented on each commit or pull request. Permission boundaries can be checked to verify they cannot be crossed. APIs can be tested to ensure they’re meeting authentication and authorization requirements. Security testing meets your developers where they already are, providing them immediate feedback on each and every commit.

Vulnerability scanning at every level of your architecture across your pipeline can verify that each section of your application and deployment is secured against known vulnerabilities. Source code can be scanned for vulnerable libraries. For example, applications can be scanned for susceptibility to XSS and SQL injection. Containers can be scanned for vulnerabilities in individual packages and for adherence to best in class practices. Full scanning of test, staging and production environments can be done continuously and automatically. Scan early and scan continuously to verify your expected security controls are in place and so that you can find issues sooner rather than later.

User and data access policies codify governance decisions that can then be reviewed by anyone in your organization. These policies can be standardized, reducing the toil necessary to constantly monitor and maintain one off requests. Authorization can be offloaded to external libraries allowing your Dev teams to focus on core features. Security teams now have a central repository to work directly with developers to monitor and review authorization, allowing the entire company to move faster without breaking core security and compliance requirements.

Genesis

Historically, organizations consisted of separate and siloed Development, Operations and Security teams. Dev teams followed waterfall development and more often than not, so did the deployment from one team to the next. Dev teams finished a project and marked it as code complete. At this point, Ops teams would then be responsible for actually getting it into production. Security teams were unfairly given a reputation for saying ‘no’ to everything and were maybe informed of this process at some point, but were often the last to know.

This operating model often pitted teams against each other with tension from one step to the next and between each of the teams. This lack of collaboration also led to long release cycles, cost overruns and ultimately delays to delivering new features and functionality that would scale and be secure. Each team had differing goals and collaboration suffered.

ORGANIZATIONAL EVOLUTION

As businesses moved to the cloud, adopted a microservices-centric architecture, and began pushing the envelope on release frequency, this operating model started to change completely. Development and Operations teams began to work together in a DevOps model. Infrastructure as a service allowed for the popularization and widespread use of Infrastructure as Code (IaC). Resources no longer needed to be specified out months in advance, ordered and physically racked in data centers. Instead, programmatic APIs could be utilized to create brand new resources on demand. Those resources could be automatically scaled up or down.

Infrastructure could now be completely created and managed using code. IaC removed the friction and toil associated with teams manually provisioning and managing fleets of servers, databases, operating systems, containers and at this point, all infrastructure associated with software applications. Dev and Ops team are no longer separate teams, but rather working together to build and scale applications together.

Security as Code builds off the gains that these organizations have seen from IaC. Security as code similarly sees a migration to security and policy as code to remove the toil and friction associated with securing software in an IaC mindset. Security and policy as code began with standard software testing of areas like permission boundaries. These unit and functional tests were Security as Code before being labeled as such. Security as Code also arose out of the desire for automation from internal and external red teams and pentesters to automate all of the things. Known as DevSecOps or DevOpsSec, this methodology has become the way organizations can enable collaboration, agility and security, early and often across their entire infrastructure.

Security as Code Benefits

When moving to a Security as Code model, there are a number of key benefits that are realized across the organization. One of the key benefits and early drivers was fostering collaboration and enabling agility between and among Dev and Security teams. Another key benefit has been visibility for many teams across the organization. Finally, codifying both security and policy simplifies management and reduces toil across the organization.

Greater Collaboration: As Dev teams moved to agile workflows, Security teams were often left behind still operating in a waterfall methodology, being brought in at the very end. Dev teams were quickly iterating and ignoring or subverting security processes that hadn’t been yet updated. Security teams that quickly recognized the benefits of agile methods started working directly with Dev teams to meet them where they were. This naturally led to collaboration when they both began to work on shared problems. No longer were they working on orthogonal problems with different motivations, they were working together, directly on the same code base, making sure tests passed before code moved to the next step.

Improved Morale: Another problem that arose in organizations was that many teams outside of Security and Compliance had very little visibility into their decisions. Dev teams hoped for an approval and were distraught with what seemed like constant no’s. As security and compliance requirements become codified, there is no longer a question as to why a decision is made, it’s clear from the code. For example, if you have integrated Kubernetes with Open Policy Agent (OPA), you can codify the users and groups that have direct access to each Kubernetes cluster. This allows you to set consistent policy that corresponds to service ownership instead of ad-hoc permission requests. If security is fully baked into your pipeline, there are fewer surprises and last minute blocks when it’s code complete.

Increased Visibility: Security as Code helps simplify and centralize user and data access reducing toil and further providing visibility. Access and policy changes can now be tracked, and requests for changes can be self service. For example, you may be using Terraform to manage IAM resources for your cloud provider. By tracking IAM changes in source code, anyone can now see all permissions and can make a pull request directly to the Terraform repo to request changes. When you centralize your decisions to a declarative policy engine, you no longer need to make the same decision over and over again in separate systems. Long gone are the scattered policies of authorization to scattered applications.

Shorter Release Cycle: When you integrate security requirements early on in design and development, issues can easily be addressed resulting in increased velocity. Dev and Security teams are no longer trying to address minor to complex to systemic issues after a new feature or functionality is “code complete”. With the advent of Security as Code libraries, application development can be decoupled from the fraught process of implementing your own custom authorization. For example, by integrating with OPA, developers can enable Role Based Access Controls (RBAC) in only the time it takes to enable the integration. Traditionally, this would have required multiple sprints from the Security, Product and Development teams to understand the requirements, what RBAC is, development time and finally full code review. Developers can focus on their core strengths and speed up application development. Additionally, as Security teams continue to adopt this approach, they will begin to adopt or develop their own libraries and tooling to further speed up releases by providing resources to ensure that applications are secure by default.

Better Security: When looked at holistically, each test, scan or policy that you can integrate, early, often and continuously, will find problems sooner so they can be addressed before others find them. Undertake this approach for all sorts of add-on benefits, but ultimately we’re all in this together to better secure the data we all care about.

Security as Code with Cyral

The principles of Security as Code and API-first have been at the core of design and development at Cyral. We have embraced cloud-first, everything as code and API-first design to meet our customers where they are.

Our commitment to Security as Code starts first with building a security product that is developer friendly. We have designed our product to naturally fit into existing development workflows. Our application can be easily deployed as part of your testing, staging and production environments to enhance tracing and security at each step of the way. No matter your setup, we have developed options to fit your deployment requirements. We have focused on IaC options from Terraform to Helm and more to support your existing workflow.

To truly be able to expand to all existing workflows, we have built our product based on API-first principles. We recognize that Cyral is only one part of your existing toolset and so we have built out dozens integrations across the stack from notifications to logging to issue tracking and more. Cyral’s focus will continue to be on data layer security and advanced data tracing across any number of data repositories available.

One of the key components of security as code is to integrate security directly into your CI/CD pipeline, bringing security testing directly and automatically as your application moves from code commit to production. For each step of the pipeline, Cyral will enable advanced tracing and consistent authentication and authorization. Cyral completely supports this model and recommends integrating Cyral in every environment to fully take advantage of our advanced security and tracing capabilities. Cyral’s application comes with out of the box templates to support your IaC workflows and install our sidecar in your infrastructure, the way you deploy the rest of your infrastructure.

Cyral can be integrated into your CI/CD pipeline and can be deployed in dev, staging and production along with your application code, ensuring that all data layer activity from every application is automatically observed, controlled and protected. By starting with Cyral in your dev environment, users can now also measure and validate that data layer performance and control do not regress with each new release. Cyral’s advanced tracing provides full visibility into what your users and your applications are doing, allowing you to triage and find issues quicker.

Cyral also utilizes Security as Code for data and access policy decisions. We have integrated with Open Policy Agent (OPA), the standard for “policy-based control for cloud native environments”, as the basis for our policy engine. OPA allows our users to write declarative policy for granular access to data repositories and the data that is contained within them. Cyral users write their declarations for user and data access in YAML. In the backend we then use this as a data input to our prewritten Rego queries to verify adherence to policy. By implementing it this way, Cyral remains performative and allows our customers to write configs in a markup language they’re likely already using. YAML also encourages all levels of internal stakeholders to be able to review, edit and comment on policy based code. Writing policy as code with YAML means that you don’t need to be an engineer to contribute.

CYRAL INTEGRATIONS

Cyral is fully committed to supporting Security as Code with our customers, and helping them improve their agility and reduce risk. Our client can have a policy repo in Github, so when they push a new version of policy to their repo, a Github Action is called to automatically update policy in their Cyral deployment. Any runtime changes in the application, as it gets promoted in the continuous delivery pipeline (for example, Spinnaker) from testing to canary to production, get tracked through metrics and traces generated by Cyral and routed to the team’s monitoring and logging platforms, such as Datadog and Jaeger or an ELK stack. If any alerts are generated they can then be sent to the messaging and issue tracking systems, such as Slack, Jira and Pagerduty. By integrating Cyral into your full pipeline, any risks and vulnerabilities are caught as soon as possible and, and all applications promoted to production by the Development team come with built in access control policies, which can be reviewed by the Security teams if necessary. Together, we have implemented a full CI/CD security and policy as code pipeline in production.

I recently came across the Synopsys  Building Security In Maturity Model (BSIMM) report and found myself enthusiastically agreeing with a number of points that it makes. If you are not familiar, the report collects quantitative data from a number of companies each year around their security practices. In it, one of the things that they highlighted was “Security is becoming part of a quality practice, which is being recognized as part of reliability, all in pursuit of resilience”.

The 11th BSIMM report collected data from 130 different large companies in a wide range of industries. The participants in this year’s report ranged from Adobe to Zendesk and included companies as wide ranging as Eli Lilly, HSBC, and Medtronic. “The purpose of the BSIMM is to quantify the activities carried out by various kinds of SSIs across many organizations.” They generate the report from the data of common security practices by surveying a wide range of companies. From there they group these into the 4 major categories of Governance, Intelligence, SSDL Touchpoints and Deployment. Each of these major categories is then broken down into sub categories such as Code Review. For each sub category, there are then 3 levels with 2 to 5 real world practices like “Use automated tools along with manual review” in Level 1 and “Automate malicious code detection” in Level 3. Based on interviews, they then assess each company to determine if they perform the task or not. 

In the early part of the 2020 epoch, 3X Engineer Paul ("pk") Pereyda Karayan and I presented at BSidesSF about the intersection of security and quality assurance. We had a simple question, “Aren’t we all just hunting bugs?” One of the key takeaways was that from a user’s perspective it doesn’t matter whether the bug is classified as a security bug or not. Oftentimes, as practitioners we lose sight of the user experience. We are so caught up in the nuances of filing bugs in Jira, we miss the forest for the trees. Over the years, this has started to pervade through Silicon Valley, most notably being Facebook’s change in motto from “Move fast and break things” to “Move fast with stable infrastructure.” As with Facebook, so has the industry started to focus on not just speed, but also on stability and resilience.

The false dichotomy inherent in focusing on security bugs necessarily sets up gates. Security needs to become part of an overall quality program. Resilience can no longer just be seamlessly recovering from infrastructure outages. One of the key ways that we talked about at BSidesSF was to formally have Security and QA teams work closely together. This necessitated a shift left mentality. Today so many talk about Shift Left solely in the context of security issues, but it was actually “first introduced in 2001 by Larry Smith to encourage more comprehensive testing done by both developers and QA earlier in the process.” Security is part of an overall quality program and should be looked at holistically as such.