Blog #5 - Security Architecture

Security architecture needs to be part of EA

Campbell (2015) outlines a scenario that I think more organizations are faced with, yet take somewhat for granted. We routinely setup systems with a production, test and development environment and most of the time our test environment nearly mirrors our production environment for load testing, disaster recovery testing and because we want things to match. Below is an excerpt from one of the Western Australia's Office for the Auditor General's report.



We are in the same boat as the statement above when it comes to maintain the same strict controls across all environments. We have outlined this as a security risk and we have started to address it. When it comes to our financial and HR systems we mask any personal identifiable information. We try to maintain a subset of information in those non-production systems if possible. We are now requiring individual access requests for those environment and requiring approval of those requests from system owner.

We certainly have a long way to go to do this across to board. However, I think we have identified a risk and are working to mitigate it.

Campbell (2015) goes on to state, "A security architect will understand the complicated tensions between the business, policy, cost and delivery, and ensures the security of systems being delivered are never compromised for the sake of making delivery easier or getting into production quicker." It is important to have someone reviewing security from the beginning of a system installation to make sure it can or will adhere to the policies at hand. We try to have most application reviewed from a SOX perspective even if they are not a SOX application because at any point they could become one. This allows us to make sure we have things like separation of duties, user access reviews and sensitive data reviews.

In all it is going to important to start including Security architecture in the overall Enterprise Architecture practice.

Reference
Campbell, Tony (2015). Why you need to build security architecture into your enterprise. Retrieved October 20th, 2016 from http://www.itnews.com.au/blogentry/why-you-need-to-build-security-architecture-into-your-enterprise-411592

Adaptive Security Architecture

I found an interesting post that touched on a bit more detail around adaptive security architecture and gave a couple area to focus on. Amrutha (2016) provides two blog post touching on adaptive security architecture. In the first Amrutha (2016) states "The adaptive security architecture can help enterprises shift their existing mind-set of “incident response,” wherein incidents are thought of as occasional, one-off events, to a mind-set of continuous response, where they assume that cyber-attacks are relentless and hackers have the ability to continuously penetrate the systems." This is an interesting statement and I think makes you open your eyes a bit if you are not directly involved with security practices.

Amrutha (2016) goes on to quote the Gartner report, "Designing an Adaptive Security Architecture for Protection from Advanced Attacks," which outlines four, high-level categories of competence.

1. “Preventive” capabilities are the preventive policies, products, and processes that are put in place to counter attacks. The key goal of this category is to raise the bar for attackers by reducing the surface area for attacks before these attacks can affect the entire enterprise. 
2. “Detective” capabilities are designed to discover attacks that evade the preventive category. The key goal behind this category is to reduce the dwell time for threat detection and therefore prevent potential damages from becoming actual damages. 
3. “Retrospective” capabilities are required to drill down and remediate issues discovered by detective activities (or by outside security services) and to provide forensic insights and root cause analysis. Retrospective proficiencies can be used to recommend new preventive measures to avoid future incidents. 
4. “Predictive” capabilities enable the security team to learn about and record external events via external monitoring of the hacker activities to proactively anticipate new attack types against the current systems. This intelligence is later used as feedback into the preventive and detective capabilities, thus closing the loop on the entire set of adaptive security capabilities. 

In Amrutha's (2016) second blog post about Adaptive Security Architecture he starts to talk about four reasons why organizations should adopt an Adaptive Security Architecture. Those are:

Most organization today continue to invest mainly in prevention-only security techniques.
The advanced security capabilities from different vendors are not integrated appropriately.
Traditional monitoring practices are becoming increasingly insufficient.
Most organizations have many blind spots while implementing incident response techniques.

Amrutha (2016) talks about moving away from prevention-only techniques and making sure you start to focus on detection, response and prediction capabilities. I know we have started to move way from just prevention. It seems like as soon as you can come to terms with the idea, "that you will never keep hackers out," the sooner you can move on to the next three areas.

He also talks about context-aware security, this is an interesting area that I want to follow up with our security group on. It seems like it could help increase the likely hood of preventing unauthorized access.

He continues to talk about increased levels of monitoring across all layers of the IT stack. This is sometimes difficult given vendor solutions. Not all vendors have build in or are concerned about monitoring their own environments as we would like them to be. We tend to just shake our heads and move on but from what Amrutha (2016) is talking about we need to start focusing on it more.

Overall, I need to get a better understanding of our currently security procedures and how we are implementing the four high-level categories of competence.

References
Aprameya, Amrutha (2016). Enhacing IT security with adaptive security architecture - part 1. Retrieved October 20th, 2016 from https://blogs.manageengine.com/it-security/2016/04/07/enhancing-it-security-with-adaptive-security-architecture-part-1.html
Aprameya, Amrutha (2016). Enhacing IT security with adaptive security architecture - part 2. Retrieved October 20th, 2016 from https://blogs.manageengine.com/it-security/2016/04/14/enhancing-it-security-with-adaptive-security-architecture-part-2.html

Risk Based Security Analysis

I was looking for more information on risk based security analysis and ran across the Crowther (2015) article. It was interesting because it established a base for risk and security. Crowther (2015) uses references to define risk as:

• Risk is the study of future bad events. 
• Risk is the study of future events that have uncertainty or unknown/ambiguous precursors or consequences. 
• Risk is the study of how bad the consequences of the bad events could get. 

He goes on to define security as:

• Security is concerned with preserving the value of an asset (or operation). 
• Security is concerned with threats that might undermine the asset value. 
• Security is concerned with the actions and responsibilities of a protector. 

What I liked about the article is that Crowther (2015) states the obvious, that it is difficult to model the future of unknown events and put a value or impact on future events without a past reference. The "zero-day" vulnerabilities are called just that for a reason. It doesn't seem like you can predict a "zero-day" breach, you can hope to react to it in an efficient manner.

Crowther (2015) goes on to talk about some false presumptions about risk management and security analysis. They are as follows:

• Risk analysis won’t make countermeasure recommendations. 
• There is not “a single, accepted risk assessment methodology. 
• Traditional risk analysis cannot help you identify unimagined, emergent threats and hazards. 
• Risk analysis does not lend itself to naive data science. 

If you have time it is worth reading his explanations of each. His explanations show how hard it is to be on the leading edge of risk management and security analysis. It is a balance of making a gut decision based on outdated information and putting in the correct measures to lessen the impact of a security event.

Reference
Crowther, Dr. Kenneth G. (2015). Do you want risk-based security analysis or security risk analysis? Retrieved October 21, 2016 from http://www.innovativedecisions.com/blog/2015/9/25/do-you-want-risk-based-security-analysis-or-security-risk-analysis

Topic #4 - Infrastructure Architecture

Does Cloud Spell the Death of Infrastructure Architecture?

Selby (2016) explores the idea how the role of the infrastructure architect has changed or will exist with the move towards the cloud. The debate is short lived on whether or not the role is dead but he certainly points out that is will/has changed. I would agree with his point the concept of infrastructure is changing however for us it is slowly changing. We have a significant investment in our data center and will continue to have that investment. One of the major hurdles we have with moving towards the cloud is that our data center is considered and asset since we own the equipment in the data center. The idea of cloud challenges our capitalization policy that we currently have in place for IT assets. That is one area that is a heated discussion when it is brought up. However, that aside I think there is a real need to figure out the right balance of cloud vs on premise infrastructure that is needed to fulfill business needs. Selby (2016) starts to touch on this with the following statement, "the Infrastructure Architect is already fast becoming the Integration Architect (IA) - a specialist in tying together services the business requires from the physical connectivity right up to the presentation layer and application delivery - and doing so on the most appropriate platform, be it in-house or with an array of cloud providers." I would certainly agree with that sediment. I think as architects we need to figure out the right blend of infrastructure it going to be key. Like Selby (2016) says, the business demands, "consumer IT ‘just works’ and seamlessly integrates, so why can’t my corporate application." It seems that this is where the role of infrastructure architecture is headed, however for us it will be a while before we get all the way there because we will still need to focus on our on premise infrastructure as well.

Reference
Selby, Rob (2016). Does Cloud Spell the Death of Infrastructure Architecture. Retrieved October 5th, 2016 from http://www.adapt.com/whats-new/blog/does-cloud-mean-the-death-of-infrastructure-architecture.html

Data center infrastructure architecture redrawn to meet new IT demands

In December of 2013, Courtemanche and Boisvert (2014) interviewed Henrique Cecci research director at Gartner Inc. about cloud and data centers at the Gartner Data Center Conference. Cecci mentions that application deployment is driving the need for new approaches to infrastructure. He also mentions the need to be able to deploy infrastructure faster than ever before in order to keep up with the application demands.

For my organization we made a significant investment in virtualization several years ago and now are reaping the benefits of that decision. There are a couple different aspects that virtualization has allowed us to excel in. The first is provisioning, we can provision a set of servers to support a new deployment in the matter of days (maybe hours) if needed. We do not need to wait on procurement of hardware to enable these new applications. Second is disaster recovery, we have been able to establish a disaster recovery strategy with complete failover to a secondary data center. I suppose maybe even a 3rd benefit is our backup strategy, we are able to take snapshots of servers prior to upgrades and revert back to the original if an upgrade goes south.

I also find the part of the Courtemanche and Boisvert (2014) interview where Cecci talks about modernizing the data center to meet demands. For me, I always looked at hardware refreshes as a way to get the most modern processing and storage power available. I hadn't thought about the efficiencies that are gained along with that. Total cost of ownership analysis like this, "If you are reducing the temperature in the data center by 1 degree Celcius, that may represent 4% energy costs in the data center", are something that doesn't seem like much on the surface but apply that thinking to infrastructure architecture as a whole and there might be more cost justification in something like a hardware refresh.

Reference
Courtemanche, Meredith and Boisvert, Michelle (2014). Data center infrastructure architecture redrawn to meet new IT demands. Retrieved October 5th, 2016 from http://searchitoperations.techtarget.com/feature/Data-center-infrastructure-architecture-redrawn-to-meet-new-IT-demands

Scaling Microservices Architectures in the Cloud

I found the article from Saini (2015) a nice short review of architecture when looking at micro services. This has been something I have been thinking about for the last few months and how we might leverage this idea of micro services. To gain the full advantage of micro services you want to be able to scale your architecture to process additional load as needed. As Saini (2015) points out you cannot accomplish this with the traditional work horse server instead you need to be able to use a multi-cluster setup. For me this is a challenge and the biggest part of it is around licensing. When I look at our licensing around our middleware servers they are core based and that becomes a problem if/when you want to scale rapidly. This is a challenge I'm trying to get my head around when it comes to hosting micro services. We are also currently mixing some batch processing, services and messaging. These three integration patterns have different infrastructure requirements, this is another area I'm evaluating to see better understand what we can/should do from an infrastructure perspective.

Reference
Saini, Atul (2015), Scaling Microservices Architectures in the Cloud. Retrieved October 9th, 2016 from https://www.fiorano.com/blog/infrastructure-architecture/