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

Read More

SOA, Redefined

Once upon a time, SOA (short for Services Oriented Architecture) was the king of IT Hype; for years people talked incessantly about it, attempted to extol its virtues and many tried using it within their own enterprise environments. SOA has had mixed success over the years, but that's somewhat hard to measure for a number of reasons, including:

1. There were conflicting definitions for it to begin with - some viewed it more as a practice or design approach, others viewed from a product perspective and still others saw it as a standards focused phenomenon. 
2. What SOA was has morphed quite a bit from where it began - it has changed so much in fact that it can hardly even be referred to in its own context any longer. We'll explain that in a minute. 
3. It was never entirely clear from the initial hype, what the real benefits of SOA would be if adopted. That has changed somewhat since the mid-to-late 2000's but that's only because the solution context evolved.

SOA drives design on the right side of this picture...

So, let's back up for a moment and first look at what SOA at several different points over the past decade. 

In the misty depths of the turn of the new millennium...

• In 2004, innovations in software engineering - notably the notion of Object Oriented programming techniques and languages along with pattern-driven design had begun to change the perception that applications must handle redundant tasks each time they faced them. In other words, the notion of software that could be shared as services through abstracted interfaces was becoming popular. The core design concept was extrapolated outwards to an enterprise scale and the first serious discussions about SOA as a practice or set of architectural principles began in earnest. 
• On a parallel track, the W3C (World Wide Web Consortium) Microsoft and several other companies began plotting out a standard communications protocol for linking software objects or services across the Internet. The standard, later called SOAP (Simple Object Access Protocol) was part of a larger set of W3C standards including XML, XHTML, CSS, DOM, WSDL and UDDI which when taken together would provide standard approaches toward encoding data, passing it and locating the places it was hiding as well as defining the format for how to display it. SOAP was adopted in 2003. 
• Also around this time a set of data management technologies emerged; partially based on EAI (Enterprise Application Integration) and ETL (Extract Transform & Load), that linked SOAP with Services concepts in the context of data movement. This new technology was called the Enterprise Service Bus (ESB).

fast forward to 2006-2008...

• A vast array of products have been restructured to accommodate the design principles which have matured somewhat. These products were formerly application server platforms and other governance management tools among others. The "SOA Stack" had been born.
• Industry hype probably reached its apex around this point. SOA projects were popping up everywhere and the idea of what SOA meant was little clearer.
• That definition focused on key design principles (such as "loose coupling" and "encapsulation" both borrowed from Object Oriented Design) and core elements of the stack (which had just evolved) - so the typical SOA solution would follow the principles and use the stack (starting with an ESB, then applying a UDDI registry, governance tool, business process manager and the appropriate app server / container, such as weblogic or websphere etc.)
• Java figured prominently in the SOA landscape, which only makes sense given that SOA evolved partially from Object Oriented Design techniques and principles. Thus, a great many of the SOA projects chose J2EE as the development language because it was designed to support OOD. 
• Some larger organizations, like the DoD, wanted to take this all further and bundle identity management and infrastructure services along with SOA initiatives. This was the beginning of a transition from consolidated hosting environments to Cloud Services in the Federal ecosystem. 
• On the commercial side, something called Software as a Service began to emerge at this time (it had in fact been around before then but got rebranded as SaaS). It involved the notion of a subscription to get thin client applications served directly from the service provider.  
• Virtualization becomes an interesting way to not waste CPU cycles in the datacenter.

2010

• Dave makes contact and the next generation of HAL computers malfunctions yet again! - sorry couldn't help throwing in the obscure sci-fi reference...
• Smart phones conquer the world. This part is accurate - it did happen and it came as a bit of surprise. It also changed the way we looked at development platforms, delivery platforms and 'object communication.' RESTful services, which had been around for awhile, got a huge boost in large part to the explosion of 'apps' being developed and deployed to IOS and Android devices. SOA would never be the same...
• Let's not forget DropBox, Google Drive and a 100 other Cloud offerings that began appearing around this time. Infrastructure got sexy.
• Oh, and everything turned "Agile."

2012 - 2014

• The longest war in American history still isn't over yet. When it started, enterprise IT was still largely mainframe driven - ten years later - what diversity we find...
• The popularity of Object Oriented Programming has hit the skids so to speak. This is because the scripting languages have overtaken J2EE in popularity as those languages support Agile and mobile platforms better (J2EE is still around of course, but then so is Cobol - the coding is on the wall). 
• People seldom refer to SOA projects anymore - or SOA has become synonymous with application architecture where organizations have more or less adopted the principles. Often times now its being done with REST instead of SOAP.

So, now that our tour of the past decade has brought us full circle back to the present; how would we go about defining SOA in 2014? Wikipedia defines it almost as a single pattern - others - like Thomas Erl - have written very interesting books on it.

Services Oriented Architecture (SOA), Redefined

SOA represents a nexus of design principles and standards for internet-driven applications. There is an implied reliance on specific toolsets that support the resulting services created based upon those principles and standards, but those tools do not define SOA any more than Object Oriented Design is defined by Eclipse. In other words, you could conceivably use any number of other tools to produce a solution that might conform to those principles or standards.  

The notion of enterprise services, Managed Services and Software as a Service (thus much of Cloud Computing) are natural extensions of the core SOA concept, but aren't SOA (anymore than SOA is OOD even though it is largely derived from it). SOA or for that matter OOD can be used to help facilitate parts of these other solutions. 

In the context of our blog here, I like to think of SOA and OOD has subcategories within the practice of Application Architecture (which itself fits within Solution Architecture). Management of enterprise services which may have been created using SOA fits into Infrastructure Architecture. Obviously, when one works on an application service that is intended to have a Cloud or SaaS element to it (or must rely on enterprise services to function), multiple architecture tiers or practice areas will be involved - which is another good reason to have IT Architects who can handle it all, right?

opyright 2014,  Stephen Lahanas

#ITarchitectureJournal
#StephenLahanas
#Semantech-Inc

Read More

Infrastructure Architecture, Defined

Infrastructure Architecture has gotten a bit more interesting in recent years as we have seen it expand into two distinct overarching categories; Physical Infrastructure and Virtual Infrastructure. Ultimately, all Infrastructure defaults to some hardware foundation, yet the revolution known as Cloud Computing illustrates how complex this field of architecture has become. Infrastructure Architecture is also referred to sometimes as Technical Architecture (in TOGAF for example).

Infrastructure Architecture today typically includes the following sub-categories:

• Data Center Architecture - This is a comprehensive view of infrastructure in the context of specific data center installations / implementations. Data Center Consolidations typically involve standardizing architectures across heterogeneous data centers as they are reduced in number to streamline operations (this is often done in conjunction with ITIL process standardization). 
• Network Architecture - This type of architecture can be internet focused (IPv4, IPv6), or include internet and telecommunications (ATM, SS7 etc.) or both. It can have a private or public (backbones or customer-facing networks) focus.
• Cloud Architecture - This includes the following core patterns: IAAS, PAAS & SAAS (infrastructure, Platform and Software as a Service). These can be configured as Public or Private Clouds. And there is now a ubiquitous category known as Hybrid Clouds which combine aspects of the previous patterns listed . This third category was developed as an approach for optimizing the resources of the previous two categories through Virtualization technology (the idea being that in many cases hardware was being under-utilized when dedicated to only a single system or purpose).

Infrastructure Architecture Definition
Infrastructure Architecture represents the sum of hardware and telecommunications related IT capability associated with a particular enterprise as well its the associated management software. The internal architecture of individual hardware devices represents a separate design field (embedded hardware). Infrastructure Architecture is concerned with the synergistic operation and management of multiple devices which when taken together offer a variety of enterprise services which the rest of the Architecture stack can exploit. Infrastructure had previously been considered a "back-end" technology capability until recently when companies like Google, Dropbox and dozens of others were able to create public facing "Cloud" offerings which successfully exploited infrastructure services direct to consumers.

This represents a prototypical view of what later become DISA Cloud Infrastructure framework

Infrastructure Architecture has also been considered (in the past) as the key focal point for IT security mainly based on the notion of perimeter security for data centers. However Security Architecture is much more expansive than Infrastructure.

We will define Cloud Computing topics in greater depth in future posts and illustrate how Architectural principles and tools are being used to help manage it.

Copyright 2014,  Stephen Lahanas

#ITarchitectureJournal

#StephenLahanas
#Semantech-Inc

Read More