InfoSec-Specific Executive Development for CISOs and Aspiring Security Leaders.
Live Faculty-led instruction and interactive labs to build you and your team's InfoSec skills
A strong security architecture can help enterprises strategically align CIO, CTO and CISO priorities, as opposed to the default approach of accumulating tactical tools and undocumented processes, which are in turn performed by people with improperly
prioritized skillsets who lack deep context of the enterprise’s business and technology.
This piece explains how to create an efficient enterprise architecture that can be maintained and support the business over time.
While several architectural approaches are available, this piece focuses on framework-neutral aspects of architecture relating to the transition from an on-prem to off-prem environment, with an understanding that both will be in play for the next
One architectural trend, accelerated by COVID-19, is that of zero trust, which can mean many different things, depending on which vendor or analyst you listen to. Zero trust can be summarized by these characteristics outlined from Google BeyondCorp:
Consider modifying the first item from the above characteristics to say the network you connect from is relevant to the access decision, but should not be the only, or even the main factor in determining access.
That said, security teams have entirely over-rotated on the virtual private network (VPN) as a security tool, when in fact being “on the network” does not confer magical security benefits. In fact, it’s sometimes the opposite: An
infected laptop can detonate the whole network via fast-moving lateral movement once landed post-VPN.
Microsoft offers some good guidance on zero trust, including a maturity model on how to approach implementation
in various stages (see Figure 1).
Of course, some of the guidance is biased toward its own products and services, but it is nonetheless instructive, even if you don’t heavily rely on Microsoft.
Many organizations are transitioning to Microsoft 365 (M365) and Azure Active Directory (AD) from Exchange and AD on-prem, with a federation between AD and Azure AD that is itself a security challenge. Similarly, on the network side, some organizations
are migrating workloads to the cloud while creating durable VPNs between on-prem data centers and their cloud providers. While this may seem like a good idea, it is yet another critical security decision that is often under-examined in a transitional
architecture, with considerations relating to what can pass through the VPN, in what direction and for how long.
These identity and network bridges could be potential disasters in the making, creating entirely new attack paths from on-prem to cloud, and vice versa, and increasing the blast radius of any breach on either side of the divide. Organizations should
tread carefully here, while making plans to sunset the permanent VPNs from on-prem to the cloud, or at least reduce the severity of the security contagion issues these choices entail (so that issues with one don’t bring down the other, and
Remember, it is still critical to maintain the security of the legacy LAN, especially in the time of ransomware, when any given compromised endpoint or server can be used to pivot and escalate to a highly privileged identity, and then to saw through
the LAN via lateral movement coupled with privilege at alarming rates.
To mitigate such disasters, Microsoft came up with a legacy privileged identity security architecture that
includes tiered administration of critical servers (DCs, servers, clients), as well as removing the de facto skeleton key of identical local admin password reuse, a common practice when IT stamps out laptop and desktop images with the same local
admin password, which, once compromised, is essentially a LAN client privileged password.
Microsoft also created a free tool, called Local Administration Password Solution (LAPS), that randomizes each client local admin password, mitigating some types of lateral movement and drastically mitigating certain types of attacks.
When it comes to building a strong security architecture, then, the idea is that organizations should focus on their legacy model for on-prem, while using the modern model for hybrid AD/Azure AD/M365/Azure scenarios.
Beyond identity and the network, a strong architecture in the new API economy must include secrets management. Here, it’s worthwhile to consider the recent Codecov breach as an example of architectural considerations relevant to how
software is built and integrated into products and services in today’s development lifecycle.
Just as many organizations are migrating to cloud services and zero trust approaches, they are also migrating legacy software development approaches to DevOps and CI/CD. Specialized tools, processes and skillsets are related to this shift in the software
development lifecycle (SDLC), and security should be deeply involved in this transition. The Codecov breach exposed how difficult it can be to trace the entire development chain, and every secret in it, as well as the effects on the
confidentiality and integrity of the code and secrets therein. This is especially true, since development is often less strict with secrets management than is production, since development secrets are often deemed less risky. However, in many
cases, this is not necessarily true.
In building out an enterprise security architecture focus on the following key considerations:
Cloud security is also an integral part of security architecture in today’s hybrid environment, and of course in cloud-native environments. For server-side concerns, one must understand that infrastructure-, platform- and software-as-a-service
(IaaS/PaaS/SaaS) each have different levels of visibility and control, and organizations must make architectural decisions related to the level of responsibility in each version of cloud services.
For example, it’s unreasonable for SaaS customers to demand their vendor provide internal network-layer logs, but it is entirely reasonable to demand authentication details and post-authentication activity logs, especially from privileged users
of the SaaS application. How do you export those logs beyond the SaaS portal? Where would they go and how would they get there?
This is a critical aspect of cloud security: Being able to monitor SaaS applications (as well as IaaS and PaaS) and having the data engineering skillset to create the plumbing that moves logs between the sources that generate them and the consumers
that ingest, store and analyze them.
Data engineering is a separate but related skillset to data science, and it must be included in any architecture team to the extent possible. Data engineering allows for repeatable patterns in data movement and distribution, so that any given source’s
logs, regardless of type or location (for example, Windows 2012 server on-prem vs. a container platform in the cloud), can be ingested and distributed to any consumer (e.g., Splunk Cloud, and/or an on-premises Hadoop data lake, etc.). Time to
value and multiple use cases for the same data source (short-term threat intel matching in near real time in the pipeline before the logs even get into the SIEM vs. six months later in the “warm” storage layer) must be considered.
In architecting for the current post-COVID reality, organizations must assume many if not most client devices are at least partly off-network, connecting to the VPN and SaaS applications. The kind of telemetry and control necessary to secure these
clients dictates that antivirus, endpoint detection and response (EDR), endpoint protection platforms (EPP), web proxies, DNS filtering and other controls are all available 24/7/365, whether the client is on- or off-network. The “big iron”
in the corporate on-prem LAN can’t be counted on to secure these off-network clients.
When approaching security architecture, remember to first prioritize the understanding of network, identity and SDLC toolsets based on the subject matter experts (SMEs) in those areas. This goes for both on-prem and cloud. If you can get the CIO and
CTO in the same room as the CISO, things can get productive since between them, there are real gaps to be bridged in terms of observability and capability to monitor, alert on and contain/remediate security events.
Skillsets such as secrets management, CI/CD, cloud security, network and identity-based controls, API security, and data engineering can all affect the success of digital transformation and zero trust initiatives.
While there is a seemingly endless list of combinations of tools and good ideas available to architects, some strategies that leverage existing capabilities, augmented with new thinking, can drastically reduce the frequency and impact of security
events, while allowing security teams to scope an incident and respond accordingly quickly and narrowly. To smooth the path, focus on:
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in connection with such information, opinions, or advice.
October 19, 2021
By IANS Faculty
Continuous compliance requires continuous monitoring and validation of controls in the environment, as well as integration with governance, risk management and compliance tools and platforms. Understand the processes, tools, stakeholders and focus required for a best practice continuous compliance program.
October 14, 2021
Learn how the DDoS threat is evolving and get a step-by-step playbook to ensure your organization is protected against DDoS attacks and has a response plan in place.
October 12, 2021
Uncertain how to secure your M365 environment? Our Faculty identify and explain the five primary areas of M365 that will provide the best security return-on-investment with the least user experience impacts.