Enterprise Security Architecture Best Practices

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. 

Efficient Enterprise Architecture 

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 several years. 

Step 1: Consider Zero Trust

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. 

Transitional Complications

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 vice versa). 

Legacy Security

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. 

Step 2:  Secrets Management

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. 

Architect for a New SDLC  

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: 

Step 3:  Consider Cloud Security 

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? 

Data Engineering

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. 

Off-Network Protections

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. 

Step 4:  Stakeholder Participation 

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. 

Enterprise Security Architecture Tips  

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.