Crypto(graphy) will Change - Drastically, I dont know...

With the SolarWinds Cyber event, Quantum Computing, & advances in Artificial Intelligence (AI) all in mind, cryptography will evolve in the 2020's.  To what degree, I don't know.

Geopolitical events & circumstances, IMHO, will be a key factor.

As events unfold, the international community will have to determine, with the private sector contributing, where we go from here.

You need a Cyber strategy

 https://devops.com/the-best-iam-practices-for-devops/

Most orgs fail to have an internal IAM policy, a partner IAM strategy (B2B), as well as a customer (B2C) strategy.  Due to that, the orgs is all over the place.

Furthermore, the article discusses unstructured data (cloud storage) that is often an issue for orgs as the lack of a strategy leads to a lack of data governance (classification, access controls, etc).  

SolarWinds breach will drive enhanced transparency & tracking mechanisms

https://threatpost.com/cloud-king-software-security-trends-2021/162442/

This article touches upon the need to have better tracking mechanisms between product teams, divisions, lines of business, & supply chains.  Couple this need with the Cybersecurity Maturity Model Certification (CMMC), & a dip in the US economy, & executives will want better tracking mechanisms to identify return on investment (ROI).

We're working on an AppSec/DevSecOps answer to this equation. 

https://www.csoonline.com/article/3535797/the-cybersecurity-maturity-model-certification-explained-what-defense-contractors-need-to-know.html

Securing Event-Driven Architecture (EDA)

 While reading this enumeration of EDA software patterns I had to think of the need for available Cyber reference architectures (RAs) and minimum security baselines (MSBs) to complement misuse test cases, especially for logic.

With cloud-native and FaaS gaining ground, as well as no/low code, Cyber will need to collaborate even closer with QA to determine any confidentiality, integrity &/or availability (CIA) issues. 

Assessing/Threat Modeling No/Low Code Applications

I'll always remember looking at a 4GL (fourth generation language) telecom app in late 2012 at an insurance company.  It was used to route, via prompts, the caller to the right service desk.

So, I embarked on an informal security assessment/threat model by handwriting on my notepad "sources | sinks" then enumerating my perceived/observed of each.  After that we walked through the business logic, error/exception handling & misuse cases.  It was not the most thorough affair, but it was a value-add to the Cyber folks.

As the industry embraces more no/low code solutions (Power Apps, Honeycode, AppSheet) it behooves Cyber professionals to use a methodology to assess these solutions.  Here's a take on such a methodology that I'll pronounce DASL:

D for Data: classification/sensitivity/compliance requirements/retention

A for Application: underlying platform (Cloud Service Provider: CSP) & security/risk/SRE/DR posture

S for Sources/Sinks: ecosystem/supply chain

L for Logic: ruleset, QA testing, misuse cases      

Discipline = Focus on Minimum Viable Product (MVP)

While orgs want to deploy a finished product immediately, that isn't practical.  From a Cyber, as well as Ops perspective, it's better to incrementally develop & deploy a solution.

Edison didn't succeed overnight; so, why should enterprises....

Separation of Duties for DevOps

Continuous integration / delivery / deployment / verification (CI/CD/CV) all need to be segmented in org's processes.  

While this may be more difficult for on-premise deployments (Jenkins / Bamboo), most cloud PaaS offerings make this easier, especially AWS with their Code* portfolio (CodePipeline / CodeBuild / CodeDeploy).

 

Cloud-Native Threat Modeling & Alignment with Design Patterns

 https://techbeacon.com/enterprise-it/7-container-design-patterns-you-need-know

When performing a threat model for cloud-native environments I advocate for a comparison to the design patterns articulated above, especially how security-centric services are deployed.  To execute on segregation of duties one must abide by said best practices.

Add D(ata) to 4C's of Cloud Native Security for Completeness

https://kubernetes.io/docs/concepts/security/overview/

The 4C's described above do not explicitly include securing the data.  Orgs need to secure their data (crytpo, masking) before it goes to the cloud, onsite, or otherwise...

Cyber Snake Oil

While some Cyber solutions certainly deliver as promised, there is a multitude of solutions that seem to be wanting.

Namely, cloud security posture management (CSPM) and secure access service edge (SASE) solutions.

Akin to first-generation web application firewalls (WAFs), CSPM and SASE solutions seem to promise a lot while skeptically delivering value.  Like WAFs, I believe organizations will see these as a tool in the Cyber toolbox that can COMPLIMENT solid hygiene versus SUPPLEMENT said governance. 

Control Frameworks - Use a Hybrid

Many orgs use a control framework (NIST 800-53, HITRUST CSF, COBIT, SIG, ISF SoGP, ISO 27002, CSA CCM) that doesnt completely express that orgs security/privacy/risk mgmt posture.

It behooves those orgs to use a hybrid mapped back to those frameworks.    

Risk Management for Vendor Ecosystem

Many orgs focus too long on assessing the risk before deciding to onboard a vendor.

Multiple control frameworks (COBIT, ISF, ISO, NIST, HITRUST) include hundreds of questions that are often redundant.

Furthermore, these assessments couple the vendor governance witht the actual solution.  Hence, orgs spending weeks on evaluating each vendor.

The solution here is a laser-focused framework that includes a base for the vendor, along with specific questions for the solution.  I would also advocate for a vulnerability scan of the solution by the specific org doing the assessment. 

Vendor (Security) Reviews are not Solution Security Reviews

 A vendor's (security/privacy) holistic governance is not the same as the security/privacy posture of the solution a larger organization is looking to procure.

The reality is that many startups/SMBs have solutions that are (considerably) different, from a cyber perspective, then their general posture.  Many (startup/SMB solutions) are based/hosted with cloud service providers (CSPs), and.therefore, require a separate level of review.

Third-party risk management (TPRM) processes and teams are prevalent in corporate organizations; however, experience shows a generic coupling of the solution with the vendor that seems inadequate.

So, it is advocated that larger organizations focus on high-level governance for the vendor-at-large, coupled with low-level verification of the solution at hand. 

How is this accomplished?  Well, focus on control frameworks (NIST, ISO, SIG, HITRUST, ISF, COBIT) for the vendor, coupled with specific deep-dives on the solution at large.  Deep-dives should include recent vulnerability scans/penetration tests/risk assessments of the specific solution from an objective third-party, with a control mapping of said solution back to organizational governance, as well as benchmarks against CSP well-architected frameworks (that are prevalent these days). 

 

Dont Replicate Your Data Center Setup in the Cloud

 A multitude of corporate IT/Cyber departments attempt to replicate their network architecture in the cloud.  Unfortunately, that is not the way to go regarding cloud transformation.  When organizations use the cloud it makes the most sense to leverage native solutions as much as possible.

While trusting cloud service providers (CSP) completely is not prudent, many CSPs have matured their services, especially security-centric solutions.  With that said, if there are any doubts/concerns, the most pragmatic choice is to leverage enterprise data protection solutions before data is migrated to the cloud.  Said solution could negate concerns about a CSP's data handling procedures.

Are SOC2 / ISO 2700x / HITRUST Attestations Enough for PaaS / SaaS Providers

 The short answer is, not alone.  Attestations outside of penetration testing reports, or the ability for an org (that desires to provision said provider's services) to run a vulnerability scan, are not acceptable.

As an individual who has provided internal security assessments, as well as many external, the scope of attestation much too often is extremely limited in scope.  Therefore, these reviews do not provide an adequate benchmark of security &/or privacy compliance or posture.

So, kick the proverbial tires; while not requiring an expensive onsite audit....

     

Well-Architected Frameworks for Cloud Service Providers (CSP)

 CSPs now have created thought leadership for architecting cloud-based workloads:

Amazon (AWS): https://docs.aws.amazon.com/wellarchitected/latest/framework/wellarchitected-framework.pdf

Microsoft Azure: https://azure.microsoft.com/en-us/blog/introducing-the-microsoft-azure-wellarchitected-framework/

Google (GCP): https://cloud.google.com/architecture/framework

Oracle (OCI): https://www.oracle.com/cloud/architecture-center.html

AWS Lambda, Serverless Function-as-a-Service (FaaS), Primer

AWS paved the way via FaaS years ago.  However, I have yet to find a succinct, aggregation of best practices on how to use & deploy these solutions.  So, here you go:

Overview/Serverless Application Model (SAM): https://d1.awsstatic.com/whitepapers/serverless-architectures-with-aws-lambda.pdf; https://aws.amazon.com/blogs/compute/building-well-architected-serverless-applications-approaching-application-lifecycle-management-part-1/; https://aws.amazon.com/blogs/compute/category/compute/aws-serverless-application-model/; https://docs.aws.amazon.com/wellarchitected/latest/framework/wellarchitected-framework.pdf

Orchestrating serverless services: https://theburningmonk.com/2020/08/choreography-vs-orchestration-in-the-land-of-serverless/

Tracing & monitoring Lambda: https://www.infoq.com/articles/tracing-aws-lambda-functions/; https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/lambda-cloudwatch-metrics-logging.html

Negating latency challenges with cold starts: https://epsagon.com/development/how-to-minimize-aws-lambda-cold-starts/

Securing Lambda functions: https://medium.com/orchestrated/steps-to-secure-aws-serverless-lambda-part-1-a6e5d1b05f45

Edge functions: https://www.stackery.io/blog/lambda-at-edge/

Securing edge functions: https://aws.amazon.com/blogs/networking-and-content-delivery/authorizationedge-how-to-use-lambdaedge-and-json-web-tokens-to-enhance-web-application-security/ 

Tagging: https://www.cloudforecast.io/blog/aws-tagging-best-practices/

Layer-7 Logging

PPT on Layer-7 Logging

A Practical Guide to Cyber-security Engagement

Introduction

Cyber-security organizations of every size have challenges, to varying degrees, of engaging their internal customers (e.g., Business Functions, Product Teams, Information Technology: IT) for a security review of a said new solution, product, feature, and/or service. Often reviews are performed later in the implementation life-cycle, in a haphazard manner, or sometimes not at all.

To remediate this recurring challenge the following text will serve as a guide for internal Cyber-security teams to execute security reviews. This will be done by establishing the present challenges, as well as providing best practices and industry guidance on what engagement options may work best. However, we must first define what constitutes a security review.

A security review is a formal process where a Cyber-security professional, or a team of said professionals, reviews the logical/conceptual model of a new solution, product, feature, and/or service aligned with a documented risk model (e.g., NIST RMF, ENISA). This review will also take into consideration industry best practices, vendor guidance, as well as an organization’s security requirements, reference architectures (RAs), policies, procedures, guidelines, and standards. It is not a manual code walk-through, a vendor review (to see if a potential/existing vendor’s Cyber posture align with expectations), or a security assessment (vulnerability scan/penetration test/Red Team exercise). Also, note that a security review is not a regulatory and/or contractual compliance gap analysis (e.g., PCI DSS, HIPAA, GxP, GDPR, NYDFS, GLBA, NERC CIP). The following illustrates the differences between these workstreams:

Ultimately, keeping these differences in mind will assist with establishing a separation of duties within the Cyber function. With that said, many organizations have their challenges establishing this separation.

Current Challenges

Many organizations have transitioned to an Agile project management methodology, particularly for software development efforts, that does not include a formal, monolithic design phase. Therefore, many organizations find a security review to hamper, or slow down, the velocity of the project. Additionally, many organizations do not have a formal governance process. Thus, tracking and process optimization are off the radar for leadership.

Speaking of efficiencies, or lack thereof, many Cyber-security Architecture/Assurance teams conduct their reviews in a siloed manner, which bypasses knowledge sharing across the function. These teams seldom request feedback with their focus on output/productivity. This creates a snowball effect regarding trust and deteriorating collaboration within the enterprise. Because of this experience, leadership becomes stuck and resistant to change due to skill-set gaps, constant personnel changes, and/or a lack of (industry/functional) knowledge regarding best practices.

This dilemma may also result in a one size fits all mindset for security reviews as well. Were as a broader view may allow the incorporation of threat modeling for (web/mobile) applications and/or cloud systems. Also, if physical devices or facilities are in scope, then effort must be made to review (and usually assess) that as well, which takes another, different skill-set. Finally, it is often found that there is friction from the need for an internal review for Cyber projects; so, effort must be made to ensure that Cyber governs its own when it comes to security reviews.

Anecdotal Best Practices

Popular opinion among Cyber-security Architects is that security reviews are a qualitative work-stream that cannot be commoditized. However, it is agreed upon that industry guidance would assist in delivering a higher quality deliverable with enhanced consistency. Therefore, the following thought leadership has been created to foster a discussion about how to best move forward.     

Engagement Options

First In, First Out (FIFO)

Driven in a reactive, event-driven fashion via Change Advisory Board (CAB) reviews and/or privileged account requests, FIFO engagements are most often found within small, immature Cyber organizations. It is often found that the tracking mechanisms, and metrics, are lacking if present at all. This option, while aligned with ITIL/ITOps best practices, is often coupled to an individual resource as well.

Boardroom

Reviews are conducted upon request on a recurring temporal (i.e., weekly) basis to a large virtual/physical audience in a gated manner. This option follows a Waterfall project management methodology and often requires multiple cycles for approval. While not Agile, this approach is best suited for teams of Cyber-security Architects who serve as generalists, or who have varying experience.

ODA Model

Named after U.S. Army Special Forces detachments (Operational Detachment-Alpha: ODA, or A-Teams), this model uses more of a peer-based, collaborative approach. Engagement is proactive with paired Cyber-security Architects, who have a specialized skill-set (e.g., DevSecOps/GitOps, Cloud, Data/MLOps/AIOps, NetSec/Telecom, IoT, Crypto, IAM/IdM, CyberOps/ITOps), acting in a collaborative manner. After-action reviews (AARs), and subsequent lessons learned, by the Cyber-security Architects allow for them to mentor and elevate the skill-set of embedded subject matter experts (SME) within a specific product team, function, and/or line of business (LOB), thus serving as force multipliers.

Outsourced

Outsourced security reviews are not as common as third-party provided vendor reviews; however, it is an option. Organizations that provide said services include managed security service providers (MSSP), independent consultants, as well as virtual Chief Information Security Officer (vCISO) providers. If utilized, the (outsource) service provider should establish a standardized, monitored process that is as platform/vendor-independent as possible. Performance and pay metrics should also be agreed upon before the commencement of services.

Hybrid

Larger enterprises seeking to mature their Cyber engagement model may utilize a hybrid model where a Senior Cyber-security Architect would leverage the FIFO approach augmented by Outsourced resources. The intent here is to ensure that reviews are conducted while additional staff come on-board and are trained accordingly. While expensive at first, this model will allow for an adequate pace towards maturity.

It is found that mature enterprises work best with the ODA Model, though it is fairly hard to find. Also, smaller organizations should embrace the outsourced model in a cost-effective manner.     

Maturity Models

Level 1: Ad-Hoc

Reviews are performed in a reactive manner verbally, or via whiteboard sessions, and if tracked at all are done so via email, JIRA tickets, or ServiceNow (SNOW) tickets.

Level 2: Defined

Reviews follow a documented, governed process using standardized outputs (e.g., templates, forms, diagrams via a consistent format [e.g., C4]). Reviews are tracked, mostly for audit purposes, via JIRA/SNOW tickets. Metrics (e.g., time to complete, function/LOB quantity, risk levels, status: open/closed/orphaned) are collected via spreadsheets if done at all.

Level 3: Measured

Reviews follow a documented, governed process using standardized outputs (e.g., templates, forms, diagrams via a consistent format [e.g., C4]) via a risk-based approach, with high-risk reviews requiring further detail (i.e., threat models via a consistent tool [e.g., Microsoft]). Governance is consistent, though workflows are antiquated (e.g., risk/issue tracking, remediation plan follow-ups).

Level 4: Optimized

Reviews follow a documented, governed process using standardized outputs (e.g., templates, forms, diagrams via a consistent format [e.g., C4]) and a risk-based approach, with high-risk reviews requiring additional detail (i.e., threat models via a consistent tool [e.g., Microsoft]). Governance and process efficiencies have been realized and are revisited on a recurring basis to ensure alignment.

To reach level-4, which most organizations have not, requires a level of both flexibility and governance. While the vast majority of organizations suffer from resource constraints, the goal is to establish processes to ensure that they are executed with the proper level of governance and standardization.