Showing posts with label Security Controls. Show all posts
Showing posts with label Security Controls. Show all posts

Sunday, December 11, 2016

Understanding Security Controls

Security Controls sound a little bit menacing upon first hearing the term, however there’s nothing scary about them – that is unless you have a large organization that doesn’t happen to be using them. Let’s start with a definition:
A Security Control is a specified behavior, process, configuration or capability – or combination thereof – designed to counter specific or non-specific technical threats to an information environment.
Now, there are controls surrounding physical security and mechanical systems; however, in this post we’ll limit our focus to IT Security Controls. Before we go too deep into what they are and how they tend to be operationalized, let’s ask the obvious question first – why do we need them?
The quick answer is that Security Controls (and yes this does imply that come as sets of controls) represent an excellent Framework around which a security architecture and program can be built. Notice I used the terms Framework & Architecture here and that’s deliberate. Being an Architect I tend to view any Framework like those used for Security Controls but also things like ITIL as more or less adjuncts to Enterprise Architecture. The reason why I think that way is because of how similar they are – in many ways one can actually employ a group of Security Controls as the de facto Security Architecture for an organization that might not otherwise have one (and there are a lot of those out there).
Security Controls are at once pragmatic (Tactical) and Strategic – in that the controls help to define not just our immediate approaches for dealing with current threats but also usually provide excellent long-term targets as well. Another important consideration for why Security Controls are so important these days is that things have just gotten a lot more complicated in regards to Cyber Security. I’ve talked about this at some length here in other posts but the bottom line is things have just as scary as those of who’ve been working with Cyber Security said they would be. Granted, we haven’t had any zero day apocalypse yet, but most of the other predictions being made since the late 90’s have already come to pass and even some that many of us didn’t think about (e.g. Russian hacking of the presidential election). Having a framework in place – one developed by hundreds of experts from around the world – helps to demystify the landscape and level the playing field somewhat. No large enterprise in this day of age should attempt to handle security entirely on their own without benefit of Security Control frameworks – it’s more than risky – it’s negligent.
So, what does a Security Control look like? Here’s one from the NIST 800-53 Security and Privacy Controls for Federal Information Systems and Organizations publication:
ACCESS RESTRICTIONS FOR CHANGE Control: The organization defines, documents, approves, and enforces physical and logical access restrictions associated with changes to the information system.
There is much more information regarding this particular control, but the thing to keep in mind is that the control is defining something based on a classification of system issues or vulnerabilities – in other words, it is a taxonomy of practice used to organize several things:
  • Audits or Assessments (that may or may not be formal in nature, but the controls provide the framework for what is to be assessed).
  • Certification (to allow a system to be included on a network or perhaps a larger certification process like SOC 1 or 2 for data centers).
  • Security Hardening (e.g. the specific tools, configurations and processes put into place to counter a particular type of threat. For Access Control this could include a specific set of roles in regards to who might be allowed access at a given level of granularity).  
Another key consideration for a Security Control Framework, like NIST, CIS or OWASP, is that they can provide a foundation around which enterprise security metrics can be built. The metrics can potentially track all aspects of security-related activity in an organization, including things like:
  • Numbers of incidents in general
  • Users accessing or trying to access restricted resources
  • Risk levels against specifically identified threats
  • Patch management
  • Network Traffic and perimeter attacks
  • Instances of sensitive data leaving the enterprise in emails, etc.
  • Attempts to download organizational information onto thumb-drives
  • And much more…
The CIS control framework even comes with its own data model which can be used to build a reporting tool / data warehouse to track this type of information. Add a tool like Tableau on top and you’ve got a pretty slick solution that’s aligned with industry best practices without having to invent the whole thing from scratch.
The key thing to keep in mind is that in most enterprises, the main threat isn’t a specific group of Russian or Chinese hackers, but rather they sheer confusion surrounding the ever growing set of tools and security practices that must be managed as “mission-critical.” Adopting and integrating standard Security Controls still allows for a tremendous amount of flexibility in how to meet that confusion, but it also helps to reduce the complexity challenge almost immediately.  
Copyright 2016, Stephen Lahanas

Friday, September 12, 2014

Security Architecture, Defined

There are some people who don't recognize Security Architecture as its own niche within IT Architecture, but given the number of roles / positions now using the title "Security Architect," perhaps the naysayers have missed out on something. This post will examine what Security Architecture consists of and how it fits within the larger context of IT Architecture.

Back in the old days, security was a lot easier. We didn't have internet connectivity everywhere, few if any viruses, and only a handful of hackers who were mostly in it for the fun. Things have sure changed. What used to be referred as "Information Assurance" or IA has gradually morphed into "Cyber Security." While IA was primarily focused on management of information assets (which included copious amounts of paper locked in vaults), Cyber Security has tentacles that reaches all the up and down every solution stack and into every nook and cranny of the newly dubbed "Internet of Things." (this year's hype king).




Security Architecture is related both the practice of Cyber Security as well as the practice of IT Architecture. We've tentatively classified it as a subset of Solution Architecture, but just like some other areas like SOA, Security Architecture proves to be a bit ubiquitous in both principle and practice. Originally, when those of us worked on Security Architecture projects, we tended to fund them primarily concerned with Data Center design (or consolidation) or more specifically focused on tightening up perimeter security within a Data Center. Now, Security Architecture has become much more expansive, including aspects of UI coding all the way to management of mobile devices (to encrypt data at rest and prevent identity theft for example). So lets move on to some definitions.

Security Architecture, Defined
Security Architecture represents the ability to represent and resolve any IT-related security issues using IT Architecture techniques. These security issues can be internal or external and can either be technology agnostic or technology specific. The solutions developed as a result of Security Architecture analysis and design are often decomposed into "Security Controls," which focused on narrowly defined portions of the overall security landscape. 


Security is still based on core IA principles but those have been expanded
 to include a much wider arena of potential action

In our initial definition, we alluded to something called Security Controls; this is worthy of further examination...

Security Controls, Defined
Security Controls are the individual measures necessary to mitigate specific security threats or concerns. These controls can be part of larger information security standards (NIST, FISMA Cyber Framework, etc) or they can be defined within specific organizations (or a combination of both could be used). The controls consist of guidelines and policies (for example, coding practices), specific configurations for systems, and test cases for security evaluation.
Management of Security Controls isn't necessarily a Security Architecture function, however definition of Security Controls often is (coming after some type of audit that may include review of the existing architecture).

Which brings us back to the larger question of what Security Architecture is and what exactly a Security Architect does. As we alluded to earlier, once upon a time it was common to associate Security Architecture with data center technology (like Intrusion Detection Systems for example) and Information Assurance with control over information or data. Today, Security Architecture spans the entire stack from infrastructure (Cloud or Traditional) through Data, Application up through to UX. It also extends out to other enterprises and to mobile platforms and social media (or other external Cloud based services). Security Architecture is always only as strong as its weakest link - and with the ever-expanding scope of operations the extent of the oversight necessary to mitigate those weak links makes the job of the Security Architect more daunting than ever before.

Security Architecture must facilitate both prevention of threats as well as active oversight of operational integrity. While the Security Architect does not sit in a NOC (Network Operations Center) he or she does often determine how operational analysts will conduct their jobs. This field within IT Architecture is an excellent example why cross-domain expertise is needed for many Architecture roles.

We will be examining a number of specific Security Architecture case studies in future posts here on the IT Architecture Journal.



copyright 2014,  Stephen Lahanas


#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc