Epignosis

The Enterprise Business Architecture, Part 1

Image Source: Aviana Technologies

In previous classes as well as the beginning of this class, we discussed how Enterprise Architecture (EA) is traditionally thought of as having 4 distinct viewpoints:

• Business Architecture Layer
• Data Architecture Layer
• Application Architecture Layer
• Technology Architecture Layer.

In recent years, the importance of security has become a much higher priority and many organizations now treat the Security Architecture as a fifth distinct viewpoint within the EA.  However it is important to note that there is a distinct flow to the parts, as noted by the wording in the above graphic.  From the top down, the layers define the scope and boundaries of the layer below them.  From the bottom up, each layer supports the architecture of the layer above it.

This week, we are talking about the Enterprise Business Architecture (EBA), the keystone of our EA “pyramid” diagram.  And as the diagram suggests, the business layer drives all the rest of the viewpoints of the Enterprise Architecture while those other viewpoints are ultimately supporting the business architecture.

Gartner defines the EBA as:

That part of the enterprise architecture process that describes — through a set of requirements, principles and models — the future state, current state and guidance necessary to flexibly evolve and optimize business dimensions (people, process, financial resources and organization) to achieve effective enterprise change.

As with information, technology and solution architectures, the EBA process translates the strategy, requirements and vision as defined in the business context into contextual-, conceptual-, logical- and implementation-level requirements. Using this process, EBA, as well as all the EA viewpoints, should demonstrate clear traceability of architectural decisions to the elements of the business strategy.

Gartner continues in the article, discussing one of the main issues regarding this concept of Business Architect, in that it is often confused with Business Context.   Business Context is defined in the article as the “process of articulating the business strategy and requirements and ensuring that the enterprise architecture effort is business-driven.”  In other words, the business context defines directly how the EA is related to the business strategy and how they interact with each other.  It gives us a perspective on how the business operates.  Back in EA872, I wrote about how the “context provides the enterprise architects with the proper frame of reference in which to link together the EA Principles, Business Strategies and Business Initiatives.”  The Business Context provides us with that frame of reference for all aspects of EA, including the Business Architecture.

So the Business Context provides the frame of reference, while the Business Architecture is the organization and structure of the business processes, organizational elements, business strategy and requirements, and business rules.  Simply put, the Business Context defines the “Why” while the Business Architecture defines the “What” and “How”.  This is true of each of the 4 other EA layers we have been reviewing in the past weeks.  Each of those layers gives us a snapshot view into the “What” and “How” of their respective fields within the business.  The Business Context not only provides the “Why” for each of the EA layers, but more importantly, it provides a method to understand how the 5 layers work together to fulfill the overall business strategy.

The Enterprise Security Architecture, Part 3

Image Source: Specops

I’ll just leave that image there so you can appreciate it’s profoundness…..

Any discussion about security needs to include our love/hate relationship with passwords.  Passwords are one of the most basic security steps used in all aspects of cyber security.  So why is it that there are so many people who have challenges with such a simple item?  SplashData, a provider of password management tools, releases an annual list of the worst password people are actively using.  This data comes from evaluation of leaked passwords from North America and Europe.  This infographic is a little large, but I thought it worth viewing.

Image Source: TeamsID (SplashData)

So why do people have so many challenges with passwords?  Specops, the source of the “underpants” photo above made this observation:

End users are wired to pick weak passwords – this goes back to cognitive psychology.  As humans we are not equipped to retain meaningless information which means we make poor password choices. Either our passwords are just outright silly or they relate to our ego, our interests or something familiar. This is evident in the many common password lists out there, where password, 123456, football, master and monkey continue to make the top 20 most common passwords selected.

Instead of relying on end users to create secure passwords, which is unlikely, IT departments need to embrace better password policy practices that enforce more secure passwords by blocking the use of common dictionary words and enable more complex passwords by mixing different complexity rules (e.g. minimum of 10 characters with all four character sets or use passphrases that are longer than 20 characters).

This statement above regarding password complexity has been the standard operating procedure within IT and the business world for many years.  Most of those practices originated back in the early 2000s  from a document published by the National Institute of Standards and technology titled, “NIST Special Publication 800-63. Appendix A” (new 2017 version). We’ve all seen the standards that have been published with the “must contain at least 1 capital letter, 1 lowercase letter, 1 number and 1 special character.”  And those passwords should be changed frequently.

Interestingly enough, the original author of the standard, Bill Burr, who is now retired, just recently was interviewed by the Wall Street Journal.  In that interview, Burr admitted that he regretted his recommendations.

The problem is the advice ended up largely incorrect, Mr. Burr says. Change your password every 90 days? Most people make minor changes that are easy to guess, he laments. Changing Pa55word!1 to Pa55word!2 doesn’t keep the hackers at bay.  Also off the mark: demanding a letter, number, uppercase letter and special character such as an exclamation point or question mark—a finger-twisting requirement.

In June, the NIST did a complete rewrite of the standard with a completely different set of recommendations.  The goal was to make obscure passwords that are easy for the user to remember, but more challenging for hackers or bots to crack.  Password expiration is no longer recommended unless there is evidence that your password was stolen.

Back in 2011, this exact sentiment was expressed by cartoonist Randall Munroe, the author of the comic xkcd.  “Through 20 years of effort, we have correctly trained everyone to use passwords that are hard for humans to remember, but easy for computers to guess.”  

Now, how long will it be before this common sense change will filter out into the business world…?

The Enterprise Security Architecture, Part 2

An XT-4200 Post & Beam Gate providing a vehicle security access point (American Security Today)

So how do we go about creating the Security Architecture?  What needs to be included and how do we measure its’ effectiveness?  One thing is clear.  The security of yesterday is no longer adequate for the risks of today.

In March of this year, the Ponemon Institute released a study named “The Need for a New IT Security Architecture“. The report surveyed more than 4000 IT and security experts from around the world.  An analysis of this report by security firm Centrify discussed the findings that concern risks created by cyber-crime, employee negligence and organizational dysfunction and the technologies respondents believe are most effective at dealing with these risks (Gibson, 2017):

Outdated Security Solutions

Organizations are concerned they will not be able to manage emerging risks because of outdated security solutions.

• 69 percent of respondents say their organization’s existing security solutions are outdated and inadequate.
• What is needed, according to 74 percent of respondents, is a new IT security framework to improve security posture and reduce risk.
• A new strategy is important in order to manage potential risks from the Internet of Things (75 percent of respondents).

Trends in IT Security Risk

The findings reveal that most risks, with the exception of globalization of the workforce, are very significant. The top cybercrime risks are:

• Nation state attackers (80 percent of respondents)
• Breaches involving high-value information such intellectual property and trade secrets (79 percent of respondents)
• Malicious or criminal insiders (76 percent of respondents)
• Cyber warfare or cyber terrorism (76 percent of respondents)

An Evolving Workplace

The workplace is changing and so are the human factor risks. While 81 percent of respondents are concerned about the inability to hire and retain security staff with knowledge and credential, employee behaviors are creating risks that pose a significant risk.

• Employee complacency about security (74 percent of respondents)
• Lack of employee awareness of security practices (72 percent of respondents)
• The inability to control employees’ devices and apps (71 percent of respondents)

Complexity and legacy drag is a familiar problem that leads to high cost and contributes to shortage of competent professionals. Complexity and outdated security architectures create risk and weaken security posture.

Complexity is a Security Risk

Complexity of business and IT operations is a significant security risk. According to 83 percent of respondents, too much complexity is making organizations more vulnerable to security threats. Other trends are the growth of data assets (78 percent of respondents) and the process of integrating third parties into internal networks and applications.

Complexity is created in part by security vendors, who for decades have sold point solutions into IT environments with little thought to integration, maintenance and the cost of expertise to maintain their products.

Important Technologies for IT

Certain technologies are needed for a new IT security infrastructure.

Respondents believe their organizations’ IT security solutions are outdated and failing to mitigate the risks of cyber-crime, employee behavior and organizational problems. The most important technologies are:

• Identity & access management (78 percent of respondents)
• Machine learning (77 percent of respondents)
• Configuration & log management (76 percent of respondents)

An Architecture to Secure Identity in a Boundaryless Hybrid Environment

As reflected in the concerns of survey respondents, aging security infrastructure and point products create complexity, increase cost and risk and contribute to the critical security staff shortages.  New security architectures that protect digital identity of all users across boundary-less hybrid environments and myriad devices are required.

We know, according to Verizon’s 2016 Data Breach Investigations Report, that the #1 cause of data breach is compromised user identity.  We know that eliminating multiple identities and passwords, combined with least-access least-privilege policy and multi-factor authentication (MFA) everywhere is one effective way to contain and prevent attackers from gaining access to critical resources.

So with all these concerns, what are the necessary elements in a contemporary Security Architecture that not only protects users and applications, but improves productivity and security?  According to Gibson, they can be summarized as:

• A modern security architecture is purpose-built, based on a goal to protect digital identity for all users across hybrid cloud and mobile environments.
• It’s built on a single code-base, with API’s SDKS’s that support security industry standards and integrates with other technologies.
• It’s constantly evolving.

Rob van der Meulen of Gartner also recently posted a similar conclusion in a security article titled “Build Adaptive Security Architecture Into Your Organization“.

Many enterprise IT security teams spend much of their time focused on preventing a cyberattack. In doing so, they have implemented a “incident response” mindset rather than a “continuous response” where systems are assumed to be compromised and require continuous monitoring and remediation.

The adaptive security architecture is a useful framework to help organisations classify existing and potential security investments to ensure that there is a balanced approach to security investments. Rather than allowing the “hot” security startup of the day to define security investments, Gartner recommends that security organizations evaluate their existing investments and competencies to determine where they are deficient.

Digital business is built upon an intelligent mesh of devices, software, processes and people.  This means an ever more complex world for security, demanding a continuous, contextual and coordinated approach.

The article went on to describe 4 stages of this new “Adaptive Security Architecture”

This concept of continuous improvement and adaptation is not new in the business world.  Applying similar principles to a Security Architecture has rapidly evolved into the only way to stay on top of the ever changing world of today’s security risks.

References:

Gibson, Mark. (February, 2017). Ponemon 2017 Report: The Need for a New IT Security Architecture. Centrify. Retrieved October, 13, 2017 from https://blog.centrify.com/ponemon-2017-report/

The Enterprise Security Architecture, Part 1

In a recent post, I talked specifically about the security challenges faced in the Big Data field.  Of the many examples referenced, the one most recently on everyone’s mind is probably the Equifax hack involving the Social Security numbers, birth dates, addresses and more of at least 143 million people.  It was a staggering amount of critical data stolen in the security breach.  Additionally, over the weeks that followed, more details were discovered regarding the breach which are mind-boggling.

• The original security breach was on March 10th, 4 days after the a security flaw in the Apache web server applications was discovered and published along with a fix.
• Equifax discovered the breach on July 29th and took some of the affected systems offline for up to 11 days to resolve the issues.
• On August 1st & 2nd, 3 top executives from Equifax sell off nearly $2 million dollars worth of company stock.
• Finally, on September 7th, Equifax publicly announced about the security breach.

Since that time, numerous executives at Equifax have either left or been let go, and the investigation has shown similarities to other cyber-attacks that were carried out by Chinese hackers, but nothing conclusive has been publicly announced as of this time (Bloomberg Businessweek).

There is a lot of ambiguity regarding the timeline of the initial breach, considering that Equifax itself originally reported that they were hacked in mid May.  However, from a security perspective, the most critical issue is why did it take 4 months before Equifax was aware that there had been a security breach at all.  The organization was supposed to have sophisticated cyber-security policies and tools in place.  Additionally, the public is most angry about why the breach wasn’t disclosed until a full month after it was discovered!

So how does an organization protect itself in today’s security challenged environment? There are the obvious steps that an individual or organization can take such as virus protection, malware protection, keeping up to date on security patches, limiting access to critical systems, etc.  But haphazard methods can no longer keep up with the rate at which hackers break through security measures and efforts.  There needs to be a plan.  For organizations, this can be referred to as the Security Architecture.  Thorn, Christen, Gruber, Portman & Ruf (2008) defined Security Architecture as:

A Security Architecture is a cohesive security design, which addresses the requirements (e.g. authentication, authorization, etc.) – and in particular the risks of a particular environment/scenario, and specifies what security controls are to be applied where. The design process should be reproducible.

Not only does there need to be specific actions taken to ensure the security of the organizations systems and data, but there needs to be a cohesive security design that governs how security is managed and controlled.  Once the organization has an Enterprise Architecture established, this should be even more comprehensive.

An enterprise security architecture needs to address applications, infrastructure, processes, as well as security management and operations.  (Thorn, et. al., 2008)

As in other aspects of Enterprise Architecture, a Security Architecture brings a measure of standardization which simplifies governance of the security as well as potentially brings cost savings to the organization.  Security resources can be deployed across the enterprise to minimize potential risks.   Of course, if keeping your security measures up to date is not part of the Security Architecture, then like Equifax, there will be harsh consequences to be faced.

References:

Thorn, A., Christen, T., Gruber, B., Portman, R. & Ruf, L. (2008). What is a Security Architecture.  Information Security Society Switzerland.

The Enterprise Technology Architecture, Part 3

In technology, just as in business in general or even life, there are risks that we all take.  Whether it’s skydiving, investing in a new startup or implementing new technology, there are always risk that need to be evaluated and weighed.  Each area of society has it’s own specific risks, and within the technology field, it is no different.  Risks that are common with technology tend to fit into these categories:

• Scalability – Will my technology be able to handle the scope that I need now as well as grow to fit the scope in the future?
• Longevity (Vendor Defocus) – Will my technology continue to be efficient and supported in the future or will it need to be quickly replaced by new technology?
• Failure to meet Expectations (Technology Death) – Will new technology I acquire actually meet my needs?
• Lack of Support  – Will the vendor/developer be able to support my needs?
• Lack of Expertise – Are there resources available to acquire which can internally support the technology for the long-term?
• Cost of Technology – Will the cost of buying and using technology becomes unaffordable?
• Data Integrity & Security – How do I keep my data safe and prevent data corruption?
• General Technology Security – Aside from data, how do I keep the rest of my technology secure?  This includes malware and viruses.
• Redundancy – Do I have the necessary backup systems in place to keep my business functioning?
• New Technology Adoption – How do I know when to implement something new?  What will be the positive and negative outcomes of the adoption?

As I talked about previously in How Do You Adopt?,  the adoption of innovation breaks down into 5 basic categories:

1. Innovators – 2.5% of the population.
2. Early Adopters – 13.5% of the population.
3. Early Majority – 34% of the population.
4. Late Majority – 34% of the population.
5. Laggards – 16% of the population.

As pointed out by Mike Blechar of Gartner, the technology risk level is directly dependent on the type of adopter involved (Blechar, 2006). This is also directly related to the vendor from which the technology is purchased.  Blechar used 5 similar categories to differentiate vendors which correspond to the same category if adopters:

• Early Impact Players
• Other Players
• Heavyweights
• Focused Players
• Consolidators

Bechar goes on to detail how adopters and vendors interact:

During the technology’s first two life cycle stages (Innovators and Early Adopters), the vendors in the market will be Early Impact Players and Other Players. As the market matures and technology enters the Early Majority stage of the life cycle, vendors that are Early Impact Players transform into Heavyweights or Focused Players. Some Other Players will disappear during the Early Majority stage, and a few may be able to become Focused Players or Heavyweights. As the Early Majority stage progresses, and to the end of the first half of the Late Majority stage, vendors may move between different classifications. Heavyweights may become Focused Players or disappear, and Focused Players may become Heavyweights or disappear. The risks of buying from Other Players that survive to the end of the first half of the Late Majority stage will remain high.

Another change happens as the technology moves into the second half of the Late Majority stage. By now, the market is approaching saturation and is beginning to consolidate. Some vendors that are Heavyweights and Focused Players will exit the market (particularly during the final Laggards stage of the technology life cycle); other vendors will be acquired or will merge to become Consolidators. As the technology life cycle draws to a close, the majority of vendors left in the market will be Consolidators. These will be the vendors that have the largest and most stable maintenance revenue and, in terms of technology risk, are the “best bets.” The technology risks associated with Other Players that survive into the second half of the Late Majority and Laggard stages are now at their highest.

The severity of the risks will change for the vendors as the technology life cycle of adoption progresses. Understanding how the risk levels change throughout the technology life-cycle can help potentially mitigate those risks by proactively addressing them.

Image Source: Blechar, 2006

References:

Blechar, Mike. (2006). Managing Technology Life Cycle Risks. (G00142109). Gartner.