Will the Owner of the System using (Open Source Software Name) please call Security?

The FBI issued a bulletin on February 18, 2016 warning government entities of a ransom ware threat exploiting a security weakness in the JBOSS application server.  It appears that versions of JBOSS prior to version 7.0 are affected.  Red Hat,  the primary support company for JBOSS,  verified the fix for the weakness on February 15.

This post is not about bashing the open source movement or Red Hat.  This is about understanding the software you are running in your environment.

I work at a government agency that received the notice from the FBI.  It caused me to consider the following:

Do we have this vulnerable software running on our network now?

Is it exposed to the outside world?

How did it get there?

How do we remediate if the answer to the first question was yes?

What’s the next potential threat?

The best situation is that you control your technology stack to the point that you already know what is running in your systems environment.  If not, it’s pretty easy to find any software package, especially if it’s a Java .jar file as open source software is predominantly.  But this does take time.  You just set the network scanners to look for it and then read the report.  If it shows up on the report, you have a problem. How big a problem?

If it’s used in a system that is exposed to the Internet, you have a big problem because the exploit door is wide open.  If the system is buried inside your network and only used by internal users, you are much better off, if you can trust your users to adhere to your organization’s security standards and protocols.  You have those in place.  Right?

How did it get there?  There are two ways: First, your own developers could have introduced it in a software system they wrote.  Open source software is great because there is no acquisition (i.e. Licensing) costs and you can find documentation with the package, on the Web, or in a book.  It’s also a great way to jump start a project because a big bunch of code is already developed and stable(?). Many developers like to use open source for these reasons.  You just need to make sure that they are paying attention to maintenance changes required by their choices and that you provide time to let them make those changes when required. Like now.  Or better yet, before now.

The second way to obtain this software is from a vendor.  Vendors providing turnkey solutions really fall under the scenario of your internal developers unless you have retained them to maintain your software.  The other way is that it was introduced by a vendor with a COTS system.  This is a different situation, especially if you are paying for maintenance.  You expect that your maintenance contract will provide coverage for problems like this.  But here are the issues you could encounter…

First, there must be a remedy available.  This is either an executable or .jar (i.e. A patch) or it’s an entirely new version to which you can upgrade.  If a remedy is available you have the basis for a plan.  If not, you have to deal with the murky world of open source software.  I’ll discuss this below.  If a remedy is available, your COTS vendor must have the resources to upgrade his code to use the upgraded component and then he must be able to deploy it to you and all of his other customers who are in the same predicament.  This takes time and people.  Time you may not have.   People he might not have.  And people you might not have to do the regression testing this change might require.

In the case referenced at the beginning, Red Hat has the resources to provide a remedy and it is available.  But what if the package that is vulnerable is not managed by a deep-pocketed open source supporter like Red Hat?  What if it’s like the OpenSSL project that’s basically four guys in a garage?  OpenSSL is one of the most important technologies on the Web, providing encryption services for over half of all websites.  Well, you might have to wait a little longer for that remedy and meanwhile you’re the one sweating it out.  What if it’s an abandoned project?  You are now on your own.  That is the darkest side of open source.

Finally, the question is whether your vendor (or your developers if this is a home-grown system) have the capacity to get your system upgraded before you fall prey to the ransom demand.  We talked about the vendor and his challenges already.  If you have your own developers supporting this system, it’s probable they’re not just sitting around waiting for things like this to happen.  This means they need to disengage from whatever it is that they’re doing now and concentrate onfixing this  problem.  And timelines slip.  Just another day at the office.

What’s the next potential threat?  Who knows?  There are security firms all over the world who make their livings testing software and working with development teams and organizations to fix security problems.  There are also hackers doing the same testing and working with other like-minded people to exploit those vulnerabilities before they are found by the good guys and fixed.  The critical period of disintermediation is not between these two events but from the time a vulnerability is found until you have the security fix in place in your systems.

So is this to say that open source software is bad?  Not at all.  Its usage just requires that the enterprise architect and the systems manager understand the risks, the resources, and the timelines required to fix security problems before they result in a breach.  It requires steadfast management of your technology stack.   It really requires complete understanding of the software comprising the systems you run.

Knowledge Management: The Other Side of the Enterprise Architecture Coin

I have two passions in my professional career.

The first is Enterprise Architecture (EA). I have been interested in this subject for the past thirty years. This passion started when I designed a system supporting the risk analysis and decision support requirements for an insurance enterprise. As I have continued my career, I realized that architecture had more to do than just with systems. It needed to understand the business and processes supported by those systems.

My other passion is Knowledge Management (KM). I became interested in this subject in the early 1990s when the ideas began to emege within the business and technology communities about the necessity to preserve the knowledge in the heads of the baby-boom generation as they began to retire. We are now about 25% of the way through that wave of retirements. How is your knowledge management program working?

Rather that being torn over which of these passions to pursue or spending only half of my time on either, I have determined that EA and KM are two sides to the same coin. It is my belief that in order for an EA program to look forward and take the enterprise into the future, it must be built upon a foundation of understanding the enterprise’s current state and how it got to be there. This requires a comprehensive knowledge management program.

I have also determine that EA and KM must be integrated. This is because EA relies on existing knowledge that has been preserved and managed in order to understand how to move forward and the act of moving forward creates new knowledge that must be preserved and managed. Unless these two activities are tightly integrated, there exists the probability that the KM knowledge base will grow further and further out of synch with the reality of the enterprise as it progresses. This then inhibits the EA function’s ability to utilize up-to-date knowledge as the enterprise makes new moves forward.

I plan to write a new set of essays about how EA and KM feed each other and how they can achieve the level of integration required to make them two sides of the same coin. Please look for them in the coming months.

The Business Calendar

Every living being has an internal clock that wants to regulate its habitual patterns. It’s called the circadian rhythm. We humans are much healthier when we allow our circadian rhythms to regulate how we live each day. Usually, we use use artificial means to awaken us earlier (e.g. alarm clocks) and stay up later (e.g. stimulants) which serves to make our bodies work less effectively because we have thrown them out-of-rhythm.

Many animals also have a circadian-like calendar that helps them manage from one year to the next. Their bodies read the changing seasons and tell them to gather food, go into hibernation, and awaken the next year. Enterprises also develop a natural annual rhythm that I call the Business Calendar.

Every Enterprise should develop, publish, and understand its business calendar. For most Enterprises, the calendar should focus on the Production Schedule. Production Schedules are easy for manufacturing concerns because that’s what they use to run the shop. They might not be so easy for service concerns because they view things more like a job shop than as a factory shop.  However, recognizing your Enterprise’s ability to be distracted by non-production work is very important regardless of the type of business in which you engage.

The Business Calendar should consider the following factors:

  • The capacity of each department to accept non-production support work through out the year.  This should be measured against the permanent staffing levels approved for each department.
  • The time boxes imposed by mandatory retooling work.  Retooling is work that must be completed to allow the factory process to handle requirements stemming from law, regulation, or priority changes.  This work generally has a firm date for when it must be completed and added to the factory process.
  • The time boxes imposed by peak processing loads when factory process stability is paramount.  It is generally not a good idea to destabilize your factory process during peak season.  You must also make sure you have a matching non-production environment in which you can troubleshoot problems in production.

Let’s Talk Information System Security

Target Corporation is still reeling from the discovery that they had been hacked and made vulnerable the financial information of millions of their customers. Other retailers have made or will make similar discoveries. Those will be announced on an on-going basis.

Information system security should be an integral part of any Enterprise Architecture program. Information system security is built in to Business-driven Enterprise Architecture because BDEA is a safeguard process as is security.

The US Federal government is under a law called the Federal Information Security Management Act of 2002, or FISMA. FISMA is the basis for various government security standards such as HIPAA and IRS Publication 1075. Frankly, these standards should be used by everyone, public and private sector, because they are rigorous and comprehensive. I would imagine that Target is thinking about them right now.

Implementing FISMA is not cheap but you can consider the cost as paying an insurance premium rather than paying an insurance claim after your system has been invaded.  At that point, your organization will have no choice but to implement a similarly rigorous security program and absorb those costs in addition to all the costs of the government fines and customer compensation that will be required.  Like the old FRAM oil filer commercial said, “You can pay me now, or pay me later”.  Paying now is far less expensive.  The cost of the negative publicity and its effect on ongoing sales will dwarf the cost of implementing the program proactively.  Implementing a FISMA-level security program does not make your enterprise instantly immune to intrusions and loss.  It does help you prove that you took all due diligence to protect data while testifying in one of the myriad lawsuits that will occur after you have been hacked.

FISMA does allow some flexibility in implementation. Once you have identified a risk, you have the opportunity to develop controls ($$) or to document acceptance of the risk with sign-off by the assuming officer. Acceptance is much less expensive out-of-pocket but the assuming officer might very well have to later justify his actions in a court of law. Another strategy is to develop a POA&M (see below) and develop the security control as the milestone.

The reference materials for these standards are quite decentralized. I have created a short primer for navigating them below. Please keep in mind that I am an Enterprise Architect and not an Information Security professional. Ask an Information Security pro to interpret these documents for you.

FIPS 200 documents the Minimum Requirements for Federal Information Systems Security.  These are the minimum security requirements for US Government agency business systems; not black ops systems.

The security model is based upon a system criticality measure for confidentiality, integrity, and availability. FIPS 199 provides the guidance to determine System Criticality.

FIPS 200 also references a Risk Management Framework. That is defined in NIST 800-37. The framework with external references is:

  • Categorize Information System (FIPS 199)
  • Select Security Controls (NIST 800-53)
  • Implement Security Controls
  • Assess Security Controls (NIST 800-53a)
  • Authorize Information System
  • Monitor Security Controls (NIST 800-53a)

FIPS 200 also specifies 17 security-related areas that must be addressed in a comprehensive security plan.  The function points (Security Controls) required to address each area are defined by the system criticality measurement.  Security Controls are the management, operational, and technical safeguards or countermeasures prescribed for an information system to protect the confidentiality, integrity, and availability of the system and its information.  The actual definition for each security control for each criticality level is found in NIST Special Publication 800-53.  There are specifications that go beyond those mandated by the standard which are deemed optional based on the environmental situation of a given system.  Criteria for auditing and evaluating these controls are found in the companion publication NIST Special Publication 800-53a.

A Security Technology Implementation Guideline (STIG) is a specific configuration for a specific technology specified by the Defense Information Systems Administration (DISA). These guidelines can also be found in the National Vulnerability Database.  The DISA versions are generally used because they are concise and well-formatted.

DIACAP is a standardized methodology for evaluating the security posture of Department of Defense (DoD) Information Systems for certification and accreditation.

A Security Finding is a specific situation where a system security control is not met.  It must be classified (Category) and have a POA&M developed.  A Plan of Action and Milestones (POA&M) is required whenever a current state of a Security Control does not meet the future state need.

Vulnerability Security Code Definitions

  • Category I – Vulnerabilities that will directly and immediately result in loss of Confidentiality, Integrity, or Access
  • Category II – Vulnerabilities that have a potential to result in loss of Confidentiality, Integrity, or Access
  • Category III  – Vulnerabilities whose existence degrades measures to protect Confidentiality, Integrity, and Access

Safeguard Processes

Safeguard processes protect the Factory Process to ensure it is not being abused.  These activities ensure that you are doing the “right” things right. The high velocity of the transactions flowing through the Factory Process means that problem transactions can be completed before it is known that they are problems. This can lead to all manner of problems. Let’s use the following example to illustrate various safeguards to a factory process.

This is tax season in the United States. Taxpayers are voluntarily computing their final tax bulls for the preceding year and are squaring their accounts with the IRS. Some people owe a little more and some people paid too much during the year and are due a refund. The IRS has implemented an electronic filing system that relies on independent software developers and web hosters to help taxpayers through the process.  This results in a system (the Factory Process) that allows the IRS to process a very large number of tax returns very quickly with little human intervention.

The IRS spot checks taxpayer accounts using the dreaded tax audit.  The IRS will select a taxpayer and ask him to visit them and bring his tax returns and records for for a designated number of past filings.  The IRS will comb through those records and determine whether the taxpayer’s filing present an honest account of reality.  This is a Safeguard process for the IRS.  The threat and execution of these audits protect the Factory Process by encouraging the taxpayers to provide honest accounting of their tax years.

Unfortunately, tax audits only protect the system from real, honest taxpayers who can be located once the IRS decides to audit them.  There is an increasing business of defrauding the IRS by filing returns for non-existent taxpayers or for taxpayers whose identities have been stolen and having the IRS deposit a refund amount in a bank account from which the money can be immediately swept beyond their reach.  This scheme depends on forged documentation that is processed before its veracity is checked.  The IRS is now using more prospective methods of identity verification and cross checking employer records against employee claims.  These too are Safeguard processes because they help prevent the processing of fraudulent transactions.

So you see, Safeguard processes can be placed anywhere within the Factory Process.  Edits and cross checks are prospective or in-line Safeguards.  Audits are retrospective Safeguards.  Both types help the IRS collect and retain the maximum amount of revenue owed by taxpayers.  It is very important to find and utilize every means to protect the Factory Process from abuse.

Risk Management: Getting Back on Track

Once the enterprise has identified a risk that can be mitigated, it becomes time to fix the problem. This should be a very disciplined activity because it was a lack of discipline the got you where you are in the first place.

I think mitigation must be approached on three fronts.

  • You must know exactly what you’re doing now
  • You must know exactly what you should be doing
  • You must utilize “gap analysis” to get from what you’re doing now to what you should be doing

I have posted essays previously that describe all three of these activities. I won’t restate those thoughts here other than to reiterate my belief that the “gap analysis” approach offers the lowest risk strategy for attaining a successful remediation. Gap analysis keeps the remediation team focused on the essential repair and keeps them from wandering off to “fix” other things that may or may not be wrong.

Remember, there are two aspects of “gap analysis”. The aspect that is easy to grasp is that the gap should be filled by creating something new to satisfy a deficiency. The more subtle aspect is that something should be removed. For example, the work-around for a process requires that workers be given access to data for which they would otherwise have no need. The access is restricted because regulators require special handling of that data. The gap analysis should be focused on two ideas: redesigning the process to eliminate the need to grant access to the data or reinforcing the data security measures governing the process. The resulting candidate solutions would need to be subjected to a cost-benefit analysis to determine the correct course of action.

Risk Management: Finding Risky Behavior

Risk is the possibility of suffering harm or loss.  The definition in the Free Dictionary also references danger.  Harm or loss for most enterprises either comes from opportunity lost or regulatory sanction.  Either way, the situation is bad for the enterprise.

Some risks can be eliminated but most can only be mitigated by exploiting your advantages and shielding your deficiencies.  This is the essence of risk management.

I think the easiest way for an enterprise to mitigate risk is to know what it is supposed to do and then do it.  In order to understand what it is supposed to do, an enterprise must completely understand its entire set of requirements and then implement processes that satisfy those requirements.  This is not something that just happens.  It must be planned, executed, and implemented.  It must then be constantly evaluated as requirements change.

Another opportunity for risk can be found in those processes between what we do and what we’re supposed to do.  Most exception processes are ad hoc and not well designed. They arise from a crisis situation where workers have a very specific problem to solve and so they solve it.  The problem is that they don’t have or take the time to evaluate their solution against the enterprise’s entire set of requirements.  This opens the possibilities that the new process allows people to do things they shouldn’t or doesn’t make them do things they should. Both of these are risky situations.

So, the first part of managing risk is to identify those processes where the enterprise is not doing what it is supposed to be doing.  This requires that the enterprise evaluate everything it does against its entire set of requirements.  I’ll discuss remediation next time.

You Don’t Need to Develop an Enterprise Architecture

If you work for an existing enterprise that has processes and systems in place, you don’t need to create an enterprise architecture. You need to understand the one you already have.

The primary reason Enterprise Architecture programs fail is because the Architects are focused on something other than the reality of the business today.  Business Leaders are fine with strategic planning but they are more interested in running the business day-to-day so they can survive to the future.  Many Architects appear to want to create a “big bang” project to introduce a new future state.  Business Leaders understand there is less risk in morphing a business from its current state to a future state.

An Enterprise Architecture plan certainly is concerned with moving the enterprise to a future state. But in order to be successful, it is equally important to completely understand the enterprise’s current state.  Think of the plan as a roadmap to the future.  Think of your understanding of the current state as being the sign post – “You Are Here”.

Business-driven EA Governance and Accountability

I suggested in an earlier post that enterprise architecture should be considered a business, not a technology, initiative. I use the term business-driven enterprise architecture to reinforce that notion.  That also suggests that regardless of who the Business Leaders choose to execute a business-driven enterprise architecture program, it is they who provide governance and accountability for its success.

I generally see the governance process executed as a steering committee of higher-level executives who meet at set intervals with a project group to settle disagreements, make decisions, and approve expenditures for going forward.  The problem with this is that the members of the governance board are generally not familiar enough with the workings of the project to really make informed decisions.

I generally see the accountability process executed even more poorly.  Usually, the person who is accountable for getting the project completed is the Project Manager who is not empowered enough to cut through the other things that tug on his resources, time, and budget.  She must report to the governance committee why the project might be lagging and only receives platitudes in return.

One approach to solving this problem is the assignment of a project sponsor who is a high-level executive who “helps” the accountable project manager get things done.  The success of this approach is determined by the level of engagement by the sponsor in the project.

The business-driven approach would have the project sponsor be a member of the governance board and be the person accountable to the board for the completion of the project.  All project managers report to the project sponsor and are accountable to him.  It is the project sponsor who works with his peers to manage the things that get in the way of completing the project.

Sometimes You Pay the Fine

No project should ever be considered without considering the cost of not doing it at all. This goes for both technical and non-technical projects.

I worked in the financial services industry for many years. Every few years I was approached by semi-hysterical business leaders who wanted to sponsor quick-and-dirty projects to satisfy some regulatory mandate. The only information they could supply was that it was a mandate and there could be fines for non-compliance.

When vetting any project, it is necessary to understand the cost and benefit of every option for satisfying the need. Quick-and-dirty is always an attempt to brush over the lack of benefit by assuming that the cost is absurdly low. While that may be true in the short run, it’s rarely true in the long run when all of the facets that were missed come to the surface as unexpected consequences of the quick-and-dirty implementation. In other words, it’s a lot dirtier than first imagined. Quick-and-dirty is never a good idea and never as cheap as first proposed.

The one option that is often overlooked is the option to do nothing. Since most mandates to organizations carry civil rather than criminal penalties, no one is going to go to jail over non-compliance. When the fine for non-compliance is low or even undefined, sometimes the correct course of action is to pay the fine when levied and invest in projects with higher payback. It is vitally important to understand the deficiency in the enterprise architecture and to constantly evaluate whether changes in the regulatory environment dictate reconsideration of the enterprise’s lack of action.