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

Read More

The IT Architect as Honest Broker

What exactly is an Honest Broker? Sometimes the term is heard in the context of political discussion, however the phrase applies to just about any field of endeavor. The role of Honest Broker refers to someone who applies their expertise in a fair and unbiased manner and more importantly communicates that expertise forthrightly without fear or concern for potential reprisal. Another way to think about the role is that the Honest Broker is the polar opposite to the “Yes Man” – a person who only communicates what others expect to hear. Why is this of value and what does it have to do with IT Architecture? I’ll try to address both of those points…

Why having an Honest Broker Matters – The obvious reason may start with the realization that if one hires an expert for their expertise, they may actually want the expert to demonstrate that value. This may not always be case of course, some people hire experts and then expect them to merely mimic precisely what they wish hear. The flaw with that is the value proposition is nearly always lost in those type of situations – any problem which required the expert in order to be corrected is that less likely to be solved. It is worth emphasizing here that this applies to any field, any profession, any industry, not just IT. The difference with IT might be that there is at least the expectation that less of the ‘Yes Men’ type roles would be accepted or tolerated because IT is the main focus of innovation these days. This isn’t necessarily the case though.

Another consideration in the overall value proposition behind having an honest broker is a related phenomenon called Group-Think. Group-Think isn’t quite the same as having people act as Yes Men per se, it is more of an organizational, self-imposed boundary to what is or isn’t acceptable to think. Thus it is a cultural phenomenon, but one that exists primarily within certain sub-cultures – these can be companies or any type of organization really. The NET effect of Group-Think existing in such an environment is an overall reduction in problem-solving effectiveness. In organizations where problem solving (either individual or collective) is not really needed, Group-Think may be considered an asset. This tends not to be the case in IT however, as the field is dynamic enough that it requires problem-solving on almost a constant basis at all levels. Group-Think can be thought of as the ‘Box’ in the phrase, “Think outside of the box.”

Architecture & The Honest Broker – In IT, we hold the advantage of having a fairly well-recognized role (at least in recent years) that turns out to be perfectly suited for combating Group-Think and solving problems at all levels. That role is the IT Architect and it represents a significant part of the overall value proposition behind IT Architecture. Here are a few reasons why IT Architects make excellent Honest Brokers:

1.      Because in IT, intelligence and open-mindedness are rewarded perhaps more often than in any other field (at least that I know of). Some might say Science in general might be the place where this really holds true, but I think not. There are aspects to traditional science that are still much more rigid than IT in regards to how non-traditional thinking is accepted. IT is results-oriented in a pragmatic way that Science sometimes isn’t.

2.      IT Architects tend to be experts in more than one area, but also tend to have the ability to become experts in others quite quickly and have to deal with many more areas where they are not expert. This imbues the Architect with a dynamic and relatively unbiased world-view; as architects we don’t see the world of problems in black and white where there is an absolute set of right and wrong choices to be made. We also embrace change because we see it every day and can easily gauge massive shifts in both technology and practice within the bounds of our own careers. The IT Architect is flexible, open-minded and most importantly of all quick to challenge their own and other’s assumptions in the performance of whatever task needs doing. This is because we haven’t built our thinking around a belief system, we’ve built it around problem-solving with direct, tangible results as our primary measure of success.

3.      And perhaps most importantly, IT Architects tend to be leaders or close to leadership roles. We are in the right place at the right time and usually talking to the right people to make a difference. Matching the skills and thinking to the situation is crucial.

Being an honest broker does not imply that someone (whether they be an IT Architect or not), can say whatever pops into their head. No, being “honest” in this sense means that the Broker is fairly assessing an issue and fairly determining courses of action and communicating that information in the manner which the organization expects it to be presented without undue restriction or censorship. As I alluded to earlier, there are some organizations which don’t value this type of role and that’s fine. Others may pretend to support it, but in practice don’t and it’s not uncommon at all for Architects to be forced to one type of conclusion or another in order to maintain their position. But ultimately, the most successful IT organizations do value this type of role and once you know you’re in that type of organization fulfilling that type of role your potential to add value as an IT Architect increases exponentially.

Copyright 2016, Stephen Lahanas

Read More

The Top 7 Reasons for Data Governance

In the Age of Big Data, many people might think that the practice of Data Governance is a thing of the past – nothing could be further from the truth. Data Governance has often been misunderstood or underappreciated and relatively few organizations have taken the time and made the investment to integrate it into their enterprise processes. So, there are actually several questions that need to be answered here:

1. Does the de-normalization of data through exploitation of Big Data technologies discount the need for Data Governance?
2. Why isn’t Data Governance more widespread if it indeed still has value and
3. What is the value proposition behind Data Governance? (what are the 7 reasons why you need it)

We’ll tackle these questions one at a time.

1 - Does Big Data Require Governance?

The immediate expectation in response to this question might be – well no - as Governance seems to represent the formal and complex approach used for both RDBMS and OLAP data structures. But does this make sense per se? Classifying a data model as normalized, star schema or a de-normalized Big Table doesn’t necessarily impact the nature of the data attributes themselves. In other words, we still need to understand that data regardless of where or how it housed – we still need to know where it comes from, who owns it, where it goes, how it is transformed and so on. If we want the data to be valid, accurate and managed across a lifecycle, Governance is still needed. The technology itself does nothing to prevent us from experiencing a ‘Garbage in / Garbage out’ situation. The adoption of new technology doesn’t imply the need to discard common sense.

2 – Why isn’t Data Governance More Accepted?

This is a tougher question and in fact can’t easily be broken down into a single reason. Some of the most common reasons include:

• To govern data you first have to understand it holistically, and that initial assessment / analysis is a generally the hardest part – and is often why things don’t progress beyond that point (as many of these assessments simply never get completed)
• Often times, all Governance within an organization may be lacking because of the perception that some processes can’t be Agile and just hold things back or slow them down too much. While there is some truth to that, there is also truth in the lesson learned innumerable times that bypassing that Governance causes tremendous impacts later (to cost, efficiency and the ability to deliver and maintain capability).
• Because sometimes the tools get confused with the practice and while there are a number of great data governance tools available – sometimes they become an obstacle in themselves (e.g. some may be considered too expensive, others too complicated or perhaps there might be too many in the mix). The reality is that a lot of Data Governance can occur before or even sometimes without making that investment. It is the practice and not the software used to facilitate the practice that really matters.

3 – Why do Most Enterprises Need Data Governance? Here are 7 good reasons that tend to represent the more or less universal value proposition:

• Data Governance reduces enterprise complexity. At first, as I alluded to earlier, the impression here might be the opposite. But one only needs consider a highly typical data Use Case to see how Governance cuts right through complexity. Perhaps the number one integration issue I’ve seen faced over the past twenty years pretty much everywhere is the proliferation of similar or even the same data across multiple systems (this can include both multiple databases and reporting platforms). This quickly leads to all sorts of confusion and ultimately costs more to manage as long as it stays, well, confused. Governance tackles this type of problem at its core, by first designating authoritative systems and then more strictly controlling the use or reuse of such data. This can translate into business rules across the stack and often results in the elimination of both redundant data elements as well as duplicate systems.
• Data Governance Enhances Security – How one might ask, does it do that? Well, precisely through some of what I’ve already mentioned; including an assessment and classification of what data assets your enterprise has as well as determination of rules and architectural requirements for safeguarding both Data at Rest and Data in Motion. All of this starts with and becomes part of Data Governance. And if we think a little deeper about it, this is only logical when we consider that Data Assets are in fact the number one target of every major Cyber-Attack ever launched. To protect your enterprise, you must first know what’s in it and secondly you must have the ability to control the flow of that information.
• Data Governance is the best 1st Step for Integration – Almost every integration challenge is at its heart a data challenge. How we transport data, transform data and keep everything aligned is to a large part dependent on how well we understand that data. Messaging / Middleware / API Frameworks / EDI / SOA /EAI – you name it - it’s all about the data. Once integration is place, it must be governed – data interfaces (through messaging or other similar mechanisms) – is actually one of the most pragmatic initial places where Data Governance can be instituted.
• Data Governance Enables more Sophisticated Capabilities – such as MDM – Master Data Management is an example of a valuable enterprise capability that simply couldn’t exist if some level of Governance weren’t in place. To deploy MDM, an organization has to understand its core business entities and how they relate to attributes and be able to control them in a consistent manner. Every MDM solution I’ve ever seen either has Data Governance built in or relies on some other existing Data Governance process. MDM is not the only capability dependent on Governance though.
• Data Governance is Critical to Achieving an Effective Analytics Solution – The last thing any organization wants to be getting different answers to the same or similar questions. Data Governance not only helps to de-conflict issues at the data level – it can be used to de-conflict entire solutions. In other words, data governance helps drive consolidation of reporting and reporting architectures as well as the source systems underneath them.
• Data Governance can Impact the Bottom Line – Having Data Governance can make your enterprise more effective, not just from an IT perspective, but also the Business perspective as well. I’ve seen many organizations reduce duplicate systems and eliminate conflicting data and experience immediate results. The amount of benefit is dependent on how many systems can be consolidated or turned off and how improving data accuracy will impact whatever the business mission of the organization may be – but in almost every case – these types of benefits will be realized to some degree.
• Data Governance is often the Keystone upon which more Effective Enterprise Governance is Built – It is a great place to start if no Governance is in place or an even better place to expand if perhaps there are already some pockets of Governance already deployed. Since Data tends to be a cross-cutter, both organizationally and architecturally – it can become the foundation for a wider Governance framework.

In my experience, even in the organizations that didn’t fully implement Data Governance, the elements which were deployed provided obvious and immediate value. The current technology trends tend to point to a heightened need for Governance rather than the other way around, especially with the massive levels of adoption of Hybrid Cloud capability. I’ll talk about that in an upcoming post.

Copyright 2016, Stephen Lahanas

Read More

Reinventing Enterprise Architecture

I've seen articles recently proclaiming that Enterprise Architecture (EA) is dead. Of course, I've seen the same proclamations for SOA, for COBOL and any number of other technologies or IT practices over the years. These premature announcements all have one thing in common - they equate the value of a technology (or technology practice) with its current position in the hype cycle rather than its actual utility. There is another thing these death notices fail to grasp - technologies aren't static and they aren't always replaced by something new. But before we dive further into this topic, perhaps it is worthwhile to revisit what the current expectations for Enterprise Architecture.

Sadly, Mark Twain is really dead now, but EA isn't...

EA, as it is currently defined…

The set of high-level design activities necessary to support IT portfolio planning and/or specific IT Transformation initiatives. While EA is typically considered primarily a business-focused activity, it is also often concerned with high-level design of data, application or security solutions. EA is typically distinguished from other types of architecture by the scope or scale of the associated problem-space.

Now, this definition doesn't capture any of the core issues associated with the typical exploitation of EA in most enterprises and the reasons why some people have determined it is no longer relevant. And, like most other aspects of technology, there are legitimate issues associated with EA and a history of many Enterprise Architecture efforts not meeting expectations. Some of the problems that have been associated with EA over the years include:

• A lack of understanding as to what value it provides
• A too narrow focus on feeding (building out) an EA repository
• Lack of connection to the actual IT solution architectures

Sometimes, when we hear the word "Reinvention" we get the impression that whatever needs to be reinvented is somehow broken; that's usually not the case and it is definitely not the case with EA. What Reinvention does imply however is that there is always a need to evolve and improve - that is how any capability, technology or set of skills remain relevant over the long-term. Reinvention allows us to enhance what works, replace what doesn't and redirect all of it in more meaningful ways. That's exactly what I'm proposing for Enterprise Architecture.

So, how does one go about reinventing a major IT field of practice? 

It starts at the beginning - the expectations for that practice. These new expectations must take into account both the lessons learned (the current criticisms) as well as the trajectory of future need. The expectations fall into three categories:

1. Greater Flexibility
2. Greater Agility
3. More Relevance

EA must become more Flexible
Some of the severest criticism of enterprise architecture comes from those who have seen EA become a means unto its own end. In other words, the practice of EA has sometimes been overly focused with the management tools used to implement it. These tools are powerful and typically include EA repositories, technology catalogs and various analytics. These tools are also typically built atop a foundation known as an Enterprise Architecture Framework. These frameworks, which I will talk about in more depth in some future posts, include TOGAF (general), DODAF (military), FEAF (federal) and Zachman (general). The Zachman and TOGAF frameworks are typically better suited for commercial environments while the government ones tend be mandated as part of the larger IT portfolio processes of the agencies involved. 

The key thing to keep in mind with Frameworks is that they merely represent meta-models of what the types of things a typical organization ought to be concerned with. In this respect they are much like ITIL (which is essentially a taxonomy of data center processes) or like standard industry EDW data models (for energy, healthcare etc.). The Framework/model becomes the schema for the EA Repository and then the tool helps architects to build visualizations using data placed into that repository. The problem is that sometimes this process of building out the repository and the enterprise view of what's happening becomes too inwardly focused and too rigid. The flexibility required moving forward is this:

1. The tools are there to help the larger process of assessing the enterprise and supporting planning. That means that the tools must also serve the process and not the other way around.
2. The meta-models are not the end-all, be-all of what can be done with enterprise architecture. Like EA itself, all of these meta-models are evolving and there will often be important aspects of what's happening in the enterprise that aren't properly covered by the framework. EA is more than any given framework and can exist beyond them or even without them if needbe.
3. The work that an Enterprise Architect does is part of a larger continuum. We'll talk about that a little more in a minute, but the key thing to keep in mind here is that the Architect and the organization need to understand where and how the work fits in - and be willing to adjust as necessary (rather than staying on the same rigid course regardless of what is discovered).

Agile EA is possible...

EA must become more Agile
This is also a popular criticism of Enterprise Architecture; that it is often a rather lethargic and abstract exercise. Well, sometimes it is true, but that of course only happens when the activity is not made Flexible (see above) or more Relevant (see below). But what does Agile really mean in the context of Architecture? Many people might think that the two concepts represent a sort of cognitive dissonance. That's not really true though. Enterprise Architecture, like any complex enterprise level activity can be made more Agile by simply changing the expectations associated with it; for example:

• That analysis or assessment activities be time-boxed and aligned with specific goals or initiatives.
• That building EA deliverables or documents serve a specific purpose, such as Portfolio review or creation of Reference Architecture guidelines.
• That EA is not a giant one-off effort, but rather a more or less permanent and iterative process, that allows for continuous innovation as an organization.

Making it Real (or at least Relevant)
This is perhaps the most important change that needs to occur, but it also happens to the be the least recognized by most groups who are actually having issues with EA. This is borne from the problems associated with lack of flexibility - namely the stove-piping off of EA from the rest of what the enterprise is doing. I've been there, seen that - an EA group producing something that is totally ignored by other groups charged with making strategy real. There is one sure way to cure this problem and that is to connect EA to the rest of the IT lifecycle. The first step in doing that is understanding where EA fits in the larger spectrum of IT Architecture and then building the necessary links between all design and governance process for IT capability. 

EA when viewed by itself, represents the strategic or business focus of the larger IT Architecture mission spectrum. It is where enterprise options are assessed and where organizational strategy becomes an actionable plan for achieving organization-wide capability. It is also the starting place for all design. This unique, combined role places it squarely in between business and technical interests and their respective stakeholder groups. The future of EA is with this role empowered to broker issues between the wants and realities of the typical enterprise. EA is not analysis for its own sake - it is an ongoing and collaborative process for ensuring that Digital Innovation or evolution occurs according to plan.

copyright 2014, Stephen Lahanas

Read More

Making the Case for IT Architecture

There are still quite a few misconceptions in regards to IT Architecture. For many, hearing the term "Architecture" in relation to any IT topic seems to imply Enterprise Architecture (EA). To others, the notion of formal design processes represents the anti-thesis of Agile or responsive problem-solving. These misconceptions are unfortunate because there has never been more architecture connected to IT in actual practice and there has never been so much need for it.

So, let's start at the top - IT Architecture is a continuum and an umbrella for every design process in the enterprise. IT Architecture is the foundation for understanding every enterprise capability as well as being the starting point for all planning and governance. The reason it serves all these roles is because it provides the necessary insight for guiding all of those processes. Without that insight, making decisions and governing IT management or evolution becomes more or less like guesswork.

Why should this be so? Well, it has a lot to do with the disruptive and dynamic nature of Information Technology; it is not all uncommon for large organizations to have incomplete information in regards to their own systems, costs and data. Often times there are redundant, distributed islands of IT that cross business units or may even involve the separation of capability across IT & business communities. Gaining a complete picture of what's going in many organizations is quite a challenge - but is absolutely necessary in order to unify systems operation and to move forward in a coordinated fashion to exploit new opportunities and technologies.

So, let's go back and address those two very common misunderstandings again…

1 - IT Architecture and EA are the same thing (and EA is useless) - now I've paraphrased some of the criticism I've heard over the years about EA, but of course there is a legitimate question there. Is there any real value to EA? First off, EA and IT Architecture are not the same. EA is a top level architecture process and represents perhaps 20% of the total architecture that occurs in the typical enterprise. EA is integrated with IT Strategy and portfolio planning and governance.

Does EA have value? Yes, it does. It represents that portion of IT architecture that helps allow business stakeholders understand their IT capability landscape. It is high level enough to function as a communications tool, a governance framework and a project estimation bench-marking tool. EA is also, when done properly, the bridge to all other solution architecture.

2 - Does Architecture inhibit Agility? This is a thorny question and a complex topic, but I will try to address it briefly. At first blush, it might appear that any formalized design process might not fit within the context of the Agile Manifesto. But there are some important considerations worth noting that tend to contradict that initial assumption:

• Agile, as a methodology, has never been effectively transferred from a system or application scope to an enterprise scope except through the adoption of more iterative, time-boxed approaches to lifecycle management. There is a good reason for this - purist Agile approaches are focused on deriving requirements through experimentation rather than up front design.
• When you move from the application development scope to the enterprise integration domain things change - a lot. The problem at this level is no longer invention, but reconciliation and complexity management. In this context, the discovery associated with design relates to existing capability and introduction of well-defined new technologies. Here, IT Architecture provides the reference point for establishing and maintaining control over what otherwise might become a chaotic environment.
• Agile is all about making the application work by any means necessary - operations is all about making the enterprise work as a whole in the most efficient manner possible.
• And even within Agile, there is a design process and that process is merely one specifically-tailored component of a larger family of IT Architecture practice.

Perceptions are often hard to change and IT Architecture is a large, emerging and complicated field of practice. After working as an architect for 16 years, I can honestly say I've never seen more organizations doing architecture work. More often than not that architecture has become an important part of their overall IT management strategy. Yet, the continued misconceptions tend to hold back the true potential of IT Architecture. Too often, people view it from the perspective of one of the many sub-disciplines (such as Agile design, etc.) rather than seeing it as a holistic enterprise resource. I think that as the realization of its true scope becomes clearer IT Architecture will become even more important in the years to come.

copyright 2014, Stephen Lahanas

Read More