Cybersecurity: It’s More Than Worms, Hacking and Phishing
To put things into perspective, let’s analogize about some information technology related initiatives. In the realm of things, accounting is like a lake, integration is like a bay and cyber security is like the Pacific Ocean. The scope of understanding required to be a cyber security expert is so vast that it fills volumes just trying to define it, let alone protect it.
The reason cyber security is so vast is that it is a strategy for mitigating risk from breach of confidentiality, lack of integrity and lack of availability of information systems and networks. Consider the number of threats that target these three things and then consider this number is only the known threats. Also, know that new threats are being uncovered daily. Moreover, threats are not all technological, some of them are socially engineered, which make them all that more difficult to defend against.
When I talk to individuals about their cyber security strategy, most times these days, the answer reflects a tactical requirement to understand the nature of the threat and take some action to institute some protection. If these organizations continue to operate in this manner with the number of growing threats, they will soon be all consumed just trying to keep up let alone operate the networks and systems. The sheer magnitude of threat management will in and of itself result the worst threat of all—denial of service.
In my recent talk at the Air Force IT Conference I discussed using a Security Incident and Event Management (SIEM) tool combined with a Governance, Risk & Compliance (GRC) tool to assist with automation of handling of cyber threats. The SIEM does a great job of allowing real incidents to be recognized, which can then be driven to closure using the GRC. In this case, closure does not simply mean handled, it means completely mitigated.
Another growing trend I see in cyber security is to allow threat management to be designed outside of the realm of enterprise architecture. When this occurs, security is implemented in a silo manner usually related to the operational focus of the IT group implementing the security architecture and solution. For example, the network group focuses on network security, while the application group focuses on access control and authorization. While common, this is perhaps the greatest weakness in a cyber security strategy and can be easily exploited by an attacker. The cyber security solution must be implemented in an integrated manner watching horizontally from network through application.
For certain, if someone wants to breach or limit access to your systems and data, they will find a way to so that is not being watched. Which brings me to the next most important point about cyber security—you cannot watch everything all the time. We’ve all seen the spy movies where they time the video camera movements so they can sneak into the building undetected. Even with the best tools on the market today, you may only be made aware of a breach after it has occurred and once it has been correlated with other known events that highlight the likelihood of breach. At this point, stopping the breach is but a bullet point on the post-mortem slide and all attention must now be focused on the impact of the breach.
So, let’s see what we’ve got so far:
- We don’t know what we don’t know
- We can’t watch everything at all times
- Many are simply trying to understand the nature of the threat
- Current security architectures are being implemented in silo manner
And, now the cherry on top, not everything that is a threat is intentional. As if cyber security wasn’t complex enough, now we’re not just policing for cyber criminal activity, we’re fending off and responding to: uneducated users, careless utility and maintenance personnel, suppliers and vendors, and general defects.
As I like to say, resistance is futile, so instead, implement a strategy that keeps you out of the fray as much as possible. Implement and ensure compliance with your security policies, educate your organization on things they can do to minimize the opportunity for a cyber security incident, catalog and value your assets, and implement tools in a concerted and integrated manner. Moreover, make it a policy to revisit this lifecycle as least two times annually.
One point I’d like to expand upon from above is catalog and value your assets. Most organizations I have worked with do not do this as a general activity. Cyber security threat management is a risk management activity. You value your assets and apply resources to protect from the most critical and high-valued ones to the least critical and lower-valued ones. If you’re in the business of arbitrage, where seconds equate to big dollars, deploy most of your budget protecting the trading systems and networks. If you’re in government, you’re going to make sure that the systems required to operate the government get the most resources applied first. Knowing where to apply your resources is the most critical aspect of the mission.
To me, cyber/info security may resemble the epitome of architecture as it requires more depth and more breadth than any other branch of architecture. Moreover, to do it right, requires the architect to have experience and understanding in multiple facets of IT architecture including network, storage, server, virtualization, application and data. The unfortunate truth, however, is that a complete security architecture is still viewed as a "nice to have", not a "must have". Most business and IT executives feel comfortable knowing that they have a deadbolt on the front and back door and the windows are locked.
Cloud Computing Pragmatics
In October of 2009 I was interviewed by GovIT Journal and in that article I presented my view that Cloud Computing is highly dependent upon the network. The actual quote given was, “Which just goes to show, the telco providers still hold all this stuff by the balls!” More than ever, based on my work over the past four months as Merlin International’s Chief Architect, I still believe this is a critical and pertinent factor regardless of your Cloud Computing architecture.
Indeed, I have relished these past few months because they have presented me with the opportunity to delve deep into the muscle tissue of Cloud Computing. One of Merlin’s key areas of success has been in providing networking and data center hardware and software. While many architects can talk a good game about Cloud Computing, few have actually walked the stack top to bottom and actually touched the underbelly of the beast. Shoot, I even became a Riverbed Certified Solution Professional, a wickedly-cool WAN optimization product and am now focusing on Network Appliance certifications next. Understanding these “organs” of the Cloud truly provide unmatched insight into what is achievable and what is hype.
Meanwhile, I’ve been deep in muck gaining real insight into what Federal government customers are dealing with in trying to provide agile infrastructures to support the growing and changing needs of their user base. It’s real easy for pundits to step up and present a vision for Cloud Computing as a configurable resource that’s capable of meeting all needs, but I really believe that is a misnomer. In fact, more than ever I believe that we need to specialize Clouds to support a specific purpose. For example, I advocate that users need separate Cloud Computing infrastructures to support their full-motion video needs and their back office applications and that these should not live on the same Cloud infrastructure; especially if utilizing multicast video capabilities.
Vendors spewing forth mumbo-jumbo about creating a group of virtual machines and deploying them in an automated fashion seem to be heavily focused on new and simplistic database and business applications. Anyone doing heavy lifting on their network, dealing with saturated WAN egress points and leveraging legacy applications know that this is a pipe dream designed for the R&D lab. Putting together a Cloud Computing architecture requires a solid Enterprise Architecture effort in which the AS-IS and TO-BE architectures are fully understood and documented and there a roadmap that describes how to move from one to the other inclusive of details, such as security, auditing, monitoring, utilization, tuning, etc.
Oh, and let’s talk about security. I’m going to be putting forth an entire blog entry shortly on the real issues with defending against cyber threats, but, needless to say, building out a Cloud Computing solution before you even implement a single sign-on solution and identity management program is a recipe for redundancy and increased overhead at a minimum and breach in the worst case.
In this article, Hord Tipton, executive director of (ISC)2, the International Information Systems Security Certification Consortium, and ex-CIO of the Interior Department and Bureau of Land Management, makes an important point that security must be baked in from the start. I couldn’t agree more. Putting a few Intrusion Prevention Systems (IPS) or Data Loss Prevention (DLP) tools as the egress/ingress points cannot stop one of the biggest security flaws we have because they are designed into the core of the applications that manage and control the data. The move to the Cloud only exacerbates these problems. However, I will admit the move to Cloud offers a tremendous opportunity to deliver security as a service and then port the applications to the new architecture to minimize the risk of potential breaches.
One thing is for sure, this Cloud puzzle is large and offers a great opportunity for efficiencies. However, we need to be pragmatic in our approach or we risk exacerbating current problems instead of solving them.
Architecture: 1000 ways to skin the cat, either way, the cat’s till dead
Thanks to @jadkins for the colorful ending to that cliched saying, which really got me thinking. Sometimes we just make certain aspects of architecture too difficult for no reason. Good design is important and can have significant financial impact if done incorrectly, but chances are the negative impact comes into play during the engineering effort, not during the architecture. To clarify my point, one must first understand what architecture is really focused on and how that differentiates from engineering.
For example, if we're designing a solution for financial services products. I can choose to take a framework approach to architecture in which we identify the common financial services components, such as securities and instruments and expose the manipulation of these components through the framework. Then we can continually add new algorithms to manipulate these same components in a modular fashion. Yet, another approach might be to examine things from the perspective of the buyer and the seller and allow each financial product to implement it's own representation of securities and instruments and orchestrate the process of selling and buying.
Either of the aforementioned scenarios is a viable architecture. In the former scenario, we can develop new computational models very quickly as long as we don't change the definition of the semantic elements. However, it can be a bit rigid since all new products must be able to define the components of its product based on these definitions. Also, sharing these products across trading partners becomes more complex.
In the latter scenario, we have a more service-oriented approach, focusing on the consumers and less on the definition of the products themselves. Hence, each service is unique, and may produce redundancy in defining the elements used to create a product, but we can orchestrate buying and selling across products in a common fashion. This approach facilitates incorporation of a much wider community since agreement is not required for the representation of elements to create a new derivatives product.
Which architectural approach is better? Well, as any good consultant will tell you it depends on your goals. If your goal is to allow your big brains to develop new models quickly to identify market making opportunities, then the first approach sounds ideal. If your goal is to enable a new derivative product to be treated as a single instrument even though it's comprised of securities that are bought and sold across a variety of exchanges, then the latter approach will probably suit your needs better than the former.
Neither scenario is optimal or guaranteed, but they both represent a means of simplifying the system enough to extend it over time without considerable re-work efforts.
When complete a design goes through an engineering effort where a software engineer will take this design and "press" it into software. During this effort, decisions are made about platform, programming language, external libraries, software development methodology, etc. Any one of these decisions, or a combination of them, may lead to the undoing of the great abstract architecture designed. For example, if the system cannot scale to the volume of financial services transactions, then that would be one major flaw. Using an open source library that ends up having a major security flaw is another potential flaw.
These scenarios are not very different than design and engineering in any other industry. The architects can design the most awesome car or impressive building, but if the engineers select the wrong parts or use inferior materials, the resulting product will never allow the architecture's brilliance to shine through. Note, manufacturers put significant effort into ensuring that their designs will work by building prototypes and testing against known environments that the product will have to operate under. Thus, from this perspective, architecture is responsible for putting forth a design that is credible before engineering commences.
Metering and Instrumentation: Two Critical and Oft Forgotten Features of Cloud Services
An interesting facet of advancement is that it tends to limit know-how over time. At one time the mechanic in your local garage could take your entire engine apart, fix any problem and put it back into running order. Today, they can put a computer on the end, read a code, and hope it provides some understanding of the problem. Similarly, the application server revolution has unfortunately led to a generation of software developers that believe that the container can do all your instrumentation and metering for you, thus removing an impetus to build this into the application. These developers lose sight that the container can only tell you part of the story; the part it sees as an observer. If you don't make more internals of your application observable, the most it can see is how often it hands off control to your application, what services your application uses from the container and when you application terminates control. Useful information, but not enough to develop large-scale real world services used by hundreds of thousands, or even millions of users.
I ran across a product the other day doing some research that I found very interesting. It was a service bus that had built in metering.
Putting the metering into the container is one way around the problem of every applications metering for itself, however, how many people are going to trust their services to this product company? Additionally, it would be very difficult to migrate this service in the future unless the metering interface was standardized or replicated in another hosting container. So, here's a place where standardization of service offerings in service containers would be a very helpful feature; and something that needs to be the focus of Cloud interoperability.
Additionally, proper inclusion of metering and instrumentation interfaces into you Cloud service means that you have greater control over the granularity of the data produced through these interfaces. Most metering solutions I've seen today are very coarse-grained and often focused on infrastructure usage, such as cost per CPU cycle or gigabyte. What if you wanted to produce a service that had tiered pricing? This would require that those service operations provide the details of each transaction to a metering service.
Instrumentation is even more complex to manage than metering as it has the potential to introduce processing latency. If you capture too much instrumentation information then the service will not be responsive, but if you don't capture enough, you may not be able to determine a pending outage until it occurs. I have seen first-hand the problems of poorly-designed instrumentation in a high-volume service.
In my first-hand experience, traditional system network management tools were used to watch the application performance including CPU, memory and storage, but were unable to determine that a process was out of control and eating up storage space quickly enough to shut it down before it completely brought down all services sharing that volume. In an elastic Cloud environment, where dynamic storage is configured to come online to minimize outages a process like that could eat up a large percentage of your storage array before you had the chance to unwind it. This was made even more complex by the fact that the service provider was unaware of the typical size of a transaction from each of its customers, so it could not assume a particular quota since that may limit a legal request.
These are real problems that could have been mitigated by an appropriate level of metering and instrumentation built into the services themselves. These sub-services could have inferred average transaction sizes and average storage usage and identified that a particular process was out of range in enough time for a human to get involved and stop the runaway process.
It's interesting to see so much attention being paid to security in Cloud Computing since this was one of the most often ignored components for those implementing SOA-based designs. It seems that the immaturity of a particular technological direction is easily identified by what aspects of a robust, mature solution are ignored in emerging implementations. To ignore metering and instrumentation in the design of your Cloud services, or believe the infrastructure will handle this for you, to me illustrates the immaturity of Cloud Computing and a nativity on the part of those implementing Cloud-based services.
When SOA Fails, Just SCA
There's a lot of points that will be made in this blog entry. To keep them straight, I will highlight them right up front:
- Vendors are getting behind SCA because it reinforces a need for tools
- The importance of architects in software development
- Untested technologies are being pushed on IT like bad drugs from the FDA
So, in this morning's email I received a notification from ActiveVOS that their CTO is a primary contributor to a new book recently released on Service Component Architecture (SCA). Having just recently completed a full investigation into SCA, two things jumped out at me: 1) SCA is heavily being driven by the vendor community and 2) SCA breaks many of the rules of SOA that have been touted by these same vendors for the past 6 years. For example, SCA rewards an implied contract versus a contract-first approach to service development. That is, the contract is derived from the programming model versus defined by the architects.
What's going on here?
My subjective opinion based on all the factors that I currently have at my disposal is that SCA is a step backwards in software engineering. It's an abandonment of the SOA principles that have failed because of lack of investment in proper architecture toward a pure programming model driven by software engineers. Thus, the goal here is once again to allow poorly-designed systems to be built by software engineers with very little architecture experience so they can claim to have some attributes of SOA. Moreover, SCA is heavily dependent upon tools for creation and management. This is a game-changer from applications that be developed with a good 'ole EMACS editor and a command-line compiler. Starting to get the picture?
I recently was sent an email by a software engineer on one of my projects claiming that based on their experiences over the past year with J2EE and BPEL that this is the way that they would build all their applications. Unfortunately, the requirements for the application they're on call for pure workflow management, not integration. Which leads me to my next point, all software needs to be properly designed by an architect. Software engineers build, architects design. Architects should have a much wider berth of experience implementing and supporting various solutions using various technologies in a multitude of environments. Having accomplished the latter, one learns the reality of taking any concept from paper to production. Unfortunately, in many organizations, the developers are not forced to participate in operational support and are never privy to the impact of their bad decisions.
Additionally, tools vendors are blurring the line between form and function of various technologies and standards. BPEL is a great example. First off, BPEL 1.0 barely supported a plausible B2B integration scenario, and now BPEL 2.0, barely out of the starting gate, is the uber platform for all BPM, SOI, Integration and workflow? Come on, let's use our heads here. At best, this standard is in its infancy and hardly appropriate for development and delivery of production systems. Still, we have pundits discussing how XPDL lost the battle to BPEL (http://itredux.com/2008/09/28/why-bpel/), which is a bold claim considering the WfMC is currently working on BPMN into XPDL compliance. Then we give this information to software engineers and ask them to make architecture decisions based on it and we wonder why the CEO thinks IT is a bunch of backwards yahoos and the Cloud and outsourcing looks like the answer out of dumbass alley.
Finally, and this distresses me the most, we have a growing number of software engineers, like the one I discussed earlier, that become entrenched in understanding how to work with these tools and technologies, become ideological about them and reject alternative methods and approaches to the detriment of the software and solutions they are building. What's more is that these software engineers work to undermine alternative opinions and slur engineers and architects who do not agree with this approach. For the past few years, we have seen this with Spring and Hibernate, and will begin to see this more and more as BPEL and SCA gain in momentum as pushed by the vendors. Perhaps the reason Microsoft has never been threatened by the Java community is that they can see these vendors and engineers are cannibalizing each other through layers of complexity to the point where Microsoft's .NET simplicity looks attractive.
If I Was An IT Manager I Would...
So, if I was an IT Manager, Chief Architect, CIO, CTO for a mid- to large-sized business today, here's the things that would be on my checklist to ensure that the systems that I was building today were maintainable, sustainable and reliable:
1. Enterprise architecture - I would ensure that all applications in my portfolio were being rationalized with the needs of the business as a whole and not a single group of users. The latter is a bottom-up tactical approach that eats at the IT budget and limits the ability to design for the needs of the business as a whole. While they are difficult to avoid building, they act like parasites sucking the IT budget from a support and maintenance perspective limiting the opportunity to build software that will propel the business forward.
2. Chief Architect - I would put a single solution architect in charge of all the software that is being built. This person would rationalize the product and tools being used based on reliable, tested technologies, not the latest fad. This person would also provide objective, not ideological direction with regard to technology selection. Many businesses today are still asking Java vs. .NET. The reason for this is that .NET offers some very powerful solutions and allows for rapid application development that can be deployed on Linux boxes using Mono if that is desirable. However, the Java bigots aren't really open to having their skills made invalid by selection of C# and .NET platform. It's like offering a natural, homeopathic cure in the face of a big pharmaceutical company or a cross in the face of a vampire; these things cause mortal wounds, hence, you cannot allow them to control the choice.
3. Get the vendors out your organization. A recent blog entry by the CEO of WSO2 listed the current Oracle suite in the gigabytes, this is not expressing the virtues of KISS. Vendors' product suites are bloated, costly and in many ways proprietary. Developing distributed systems is complex, but can be made simpler by reducing the number of moving parts. The number of artifacts required to develop a SCA application is double to triple compared to the number of artifacts to create the same application using SpringWS. A properly-designed SOA reduces complexity, while these supposed SOA tools increase complexity significantly. Vendors know you are desperate for resources and will take advantage of this fact today ultimately locking you into a product selection that will be extremely costly to back out of in the future.
In Conclusion
Ultimately, the rubber needs to meet the road, and work needs to get done. The recommendations I make above are subject to the biases of the individuals and their experiences, but this too can be mitigated (to a degree). The CAEAP has an oath of professional conduct that if adhered to by the professional will lead to the best decision, even if that decision is not the preferred one of the architect. IT resources--specifically engineers and programmers--make their living based on their skills; the more their skills are in demand the greater the value and the more money that can be earned. Businesses would do well to stop hiring resources based on individual technology skills (except if you're hiring a consultant, because that's what you're buying) and start hiring based on the individual's ability to think your business to success.
Years ago, mid-80's, when I was interviewing for positions, businesses used to take pride in testing how programmers thought about problem solving, today, they look for buzzwords. Which brings us back to SCA. It won't be long till these three letters start showing up on resumes. Will your organization succumb to the pressure to use a tools-oriented approach to developing inferior networked applications that will need to redesigned and redeveloped in a few years, or will you avoid the peer-pressure sand trap this time and continue working toward a properly designed solution that will carry your company forward?
The Impact of Making Product Choices Using Qualitative vs. Quantitative Analysis
As part of my job, I help customers to select the appropriate software to either fulfill a need or as a component of a larger solution. Fulfilling this role means comparing similar software offerings and selecting the best fit. The challenge in this goal is to map the vendor offering into a subjective requirement, such as "best fit".
Throughout my career I have acted in the role of consultant, architect and analyst. In each role, I have had the same challenge of identifying the best in particular product category. As a consultant/architect, the selection criteria was based on either an enterprise need or a single solution need. As an analyst, the challenge was a bit more difficult because the criteria was based on being a solution to a problem domain.
Ultimately, comparing and scoring different products can take two approaches: qualitative and quantitative. Both can be useful depending upon what you are looking to achieve. I have found that I prefer to be a qualitative analyst than a quantitative one because in most cases I find ratings useless and arbitrary, whereas a qualitative answer illustrates depth of reasoning for a particular outcome.
I once walked away from an assignment because the research firm wanted me to quantitatively compare CORBA, DCOM and RMI as distributed object computing frameworks. As much as I tried to explain, that they all have equal merit, the ultimate decision if one is better than the other is the environmental factors, not the individual technology. Unfortunately, that fell on deaf ears in a firm grounded in scaling each feature 1 - 10.
With regard to qualitative and quantitative analysis of particular products, it gets even more interesting when you start to get the vendors involved. A quantitative matrix usually entails requesting if a product supports a particular piece of functionality. For example, do you support LDAP. Having worked for multiple software vendors, I can tell you filling out these questionnaires by analyst groups can be an entertaining activity. While certain features are straightforward, there were plenty where the answers got as interesting as, "yeah, if we hang Jim out the 3rd story window on a windy day, while he's scratching his a$$, I think it we could do X." Hence, the resulting set of answers tells you if a vendor's product has a certain level of completeness, but it doesn't go into enough qualitative depth to decipher if the implementation is any good. Moreover, even if the implementation is good, does it fit the purpose for which it will be applied?
An additional benefit of doing qualitative analysis over quantitative, and one that is critical to product vendors, is that you can truly identify where products are differentiated. For example, many of the SOA platforms out there today, on the surface, all seem to provide similar functionality. What really differentiates them is intangible's, such as how much training is required for a developer to be productive or how easily can you build and deploy a service. Quantitatively, IBM's WebSphere's platform clearly wins time and time again when comparing SOA platforms on completeness, but if one explores how much training is required and how many steps are required to build and deploy a simple Hello World service, the simplicity of a Spring Web Services container becomes more attractive.
Ultimately, I believe that this divide is central in IT failures. Products are selected based on the wrong criteria. Products that are selected quantitatively, may not be the right product for a given environment. IT groups that go outside the "popular" choice and leader quadrant on the Gartner reports and look at how a particular product supports their specific needs for a given solution are often more successful. Additionally, while not popular due to how it increases product proliferation, businesses will be more successful if they stop overloading their product selections with Enterprise requirements and select their product more tactically. While this seemingly hurts the pocketbook, the losses in productivity and inefficiency--which is often not managed and, hence, difficult to compute--will outweigh the licensing and product management issues.
The Most Important Lesson I've Learned About the Information Technology Industry
It's taken more than 10 years, but I finally got it through my thick skull:
A design is only as good as the potential for it to be put it into practice.
I tend to come up with extremely elegant, agile and extensible designs. What I've learned, however, is that not everyone sees the elegance of the design as quickly as I do. They either are unable to see the value because of lack of experience or because other pressures are forcing them to limit their attention span to produce less elegant solutions faster even if they might incur the cost of having to be re-designed at a future point in time.
While I am glad to finally be able to accept this truth, it is a bit disheartening, because it means that most businesses are truly limited in its ability to apply technology effectively to their business problems. However, accepting this postulate means that now I can focus my attention on how to help them injure themselves the least. Most importantly, I learned that sometimes, we have to change the requirements because we cannot change the people or the tools.
Hence my new postulate:
Faster, Cheaper, Better -- Pick any 2
People, Tools, Elegance -- Pick any 2
Disclaimer
My Most Recent Book
:Other Links
Web Profiles
Recent Posts
- Cybersecurity: It’s More Than Worms, Hacking and Phishing
- Cloud Computing Pragmatics
- The Real Impact of IT Owning Your SOA Effort
- Architecture: 1000 ways to skin the cat, either way, the cat’s till dead
- The Busy Executive’s Service Oriented Architecture Reference Guide
Tags
Recent Comments
- Steve Hughes on Cloud Computing Pragmatics
- CloudSigma on Cloud Computing Pragmatics
- Is ‘Service-Oriented Approach’ a Better Way to Define SOA? | SOA Governance - Service Oriented Architecture - SOA Business - SOA Design - SOA Services - SOA Software - SOA Solutions - SOA Security - SOA Web Service on Perhaps SOA is More Strategy Than Architecture
- Jaime Ramirez on The Busy Executive’s Quick Cloud Computing Reference Guide
- gon zalez on The Busy Executive’s Quick Cloud Computing Reference Guide
Blogroll
Other Links
Archives
- September 2010
- July 2010
- February 2010
- January 2010
- December 2009
- November 2009
- October 2009
- September 2009
- August 2009
- July 2009
- June 2009
- May 2009
- March 2009
- February 2009
- January 2009
- September 2008
- August 2008
- May 2008
- December 2007
- November 2006
- April 2005
