ELIMINATION OF RISKS IS NOT A BUSINESS GOAL
A corporation has various business goals, many of which involve profit expectations and return to stockholders. Lapses in the development of a corporate architecture and security risks to data storage and processing can stifle business profit goals. Although there are a few industry and government regulations intended to strengthen a corporation's information security posture, no regulation should be considered a one-size-fits-all solution. In my experience, many "InfoSec" regulations have proven insufficient. Although they foster the perception of risk discernment, they provide limited assistance in the prevention and mitigation of vulnerabilities. Regulations seem to focus on the common measures of prevention without addressing the holistic network architecture. Without sufficient identification of security risks, it would be difficult to measure the business goal of sustainability. Newton's Third Law of Motion states that for every action, there is an equal and opposite reaction. Likewise, every customer record processed for storage has an equal and opposite method of extraction -- in fact, it has multiple methods of extraction. The security goal of record keeping should not be to eliminate risks. That just cannot be done. The goal should be to detect the presence of vulnerabilities and create a framework that significantly decreases the level of risk.
BASIC THREATS TO AN ORGANIZATION
Not every business has the same problems, but the threats to information security are likely similar. Basic threats include unpatched and outdated systems, open Internet browsing, weak workstation security controls, untrained and or insufficient staff, malicious software, and weak network environments.
According to the tenets of defense in depth, there are three elements that an organization must incorporate in its information security plan:
- Defense of the networks
- Defense of the enclave boundaries
- Defense of the computing environment
Defending the networks will strengthen confidentiality of customer data and the integrity of the network. Defending the enclave boundaries involves the appropriate deployment, configuration, and management of firewalls, intrusion detection systems (IDSs), intrusion prevention systems (IPSs), and other hardware-based protections. Defending the computing environment encompasses access control protections. Now, let's define these elements further and discuss applicable means of defense for each.
Defense of the Networks
Confidentiality is the idea of ensuring that information and data remain private and secret. In the case of a healthcare provider, this could mean adopting a method in which patient health information remains concealed and can only be evaluated or transmitted to regulated individuals and organizations. It requires protecting the most sensitive patient data from unauthorized access. Integrity is the manner in which data is protected from modification or deletion by authorized or unauthorized users. The defensive mechanisms for networks include passwords, encryption, and designs for access control lists.
Defense of the Enclave Boundaries
Enclave boundaries are those points in a network that are separated from the general computing activities and contain the most sensitive data. Large entities will have multiple enclaves, while small to medium businesses (SMBs) will generally have one main enclave. It is here that you will most often see a direct relationship among firewalls, IDSs/IPSs, and other security hardware. This relationship will require you to aggregate logs from each device, and it will help you build a more usable picture of your threats, attackers, and vulnerabilities. If there is no correlation of logs, you are not utilizing one of the main strengths of the hardware on your network. Utilize every server or security hardware device to associate attack awareness and correlate knowledge.
Access to the enclave is often restricted through the implementation of policies and processes on servers and hardware that programmatically restrict access. Network appliances deployed can include packet-filtering firewalls that decide whether or not information requests should be forwarded into a network, Web application firewalls (WAFs) that work as a website filter between the Internet and a Web server, routers and switches with capabilities to control traffic flow, and proxy-based firewalls that aim to forward data requests to the intended destination.
Defense of the Computing Environment
Defending the computing environment entails utilizing hardware and software approaches to ensure privacy of data. It is likely that most SMBs have a basic firewall, but that will not sufficiently guard against the multitude of current Internet-based attacks. Defenses can include software and hardware to prevent host-based attacks (e.g., viruses, worms, malware), data injection activities (e.g., SQL injection [SQLi] or cross-site scripting [XSS]), and attempts to make server resources unavailable through a denial of service (DoS).
MODELING BUSINESS RISKS, TECHNOLOGICAL RISKS, AND THE UNKNOWN
A reputation is important to a business, and from a nontechnical perspective, it can be measured.1 To maintain a positive digital reputation with one's client base and within the body of regulations, a business needs to identify risks. A risk has two characteristics: it is first a business risk, and it is next a technological risk. The same holds true with Internet-based applications. There are common business risks, such as loss of reputation or the financial loss from a cyber attack. There are also technological risks and business logic risks. A technological risk might be the use of outdated rulesets in a WAF. An illustration of a business logic risk in an application would be following a website process through an accepted means, while at some point adding an unexpected routine that was not accounted for.
One example could be an online bank that uses a pre-programmed workflow with a standardized method of transferring money from a credit card to a bank account. Imagine a user who wants to transfer $1,000 from a credit card to a savings account via the Internet. The expectation is that the user has logged onto the system and will follow certain pre-programmed steps (i.e., entering the credit card number and the dollar amount), while a third-party credit card system will automatically process an approval/denial for the transaction. Upon authorization from the external system, the user's Internet browser will then transmit an approval code and an amount to the banking application. The business logic here is that the person will have used a pre-programmed process of approval for this savings account transaction. An unexpected business flaw is that the customer is utilizing a Web proxy to capture the third-party approval and is able to increase the savings deposit amount to $10,000 before the process completes the interaction with the banking system. This is known as boosting an account balance. It is a business logic flaw that has broken the workflow of an application.
Business risks can often be measured and accounted for. Technological risks, like the above business logic example, are generally unknown, and hence they are more difficult to measure. When attackers exploit a vulnerability, their actions will have a negative impact on business profitability goals. In order to understand the entirety of business and technological risks and to sufficiently limit damage to profitability, businesses should consider performing an architectural risk assessment.
CONDUCTING AN ARCHITECTURAL RISK ASSESSMENT
An architectural risk assessment is not a penetration test or merely a vulnerability scan. It is an engineering process with the aim of understanding, defining, and defending all the functional output from customers, line workers, corporate staff, and client-server interactions. Performed correctly, it will empower the technology staff and enable the business to focus less on security and more on customers. Penetration tests, also known as ethical hacking, are generally referred to as assessments of a running Web, mobile, or thick client (e.g., desktop) application. Architectural risk assessments include ethical hacking, source code review, and the formation of a new network design.
Staff Interviews
The first step of an architectural risk assessment is to conduct interviews with line workers and technology staff. Line workers are those people who interact with the customer on a daily basis and know many of the issues that might negatively affect customer interactions with a running application. These staff members "know without understanding" (the technical details, that is), and this knowledge will benefit the redesign of the network architecture. Interviews with technical staff will build the foundation for new or modified diagrams of the architecture. From these interviews, ensure that you receive the current design documents and use a JAD session to flush out any of the missing details.
The final interviews are with management. Management personnel can communicate the business goals, which will then be matched up with security goals. Use all of these interviews to gather requirements in the same way as if you were developing a product for the first time -- the difference being that this new product will encompass the entire corporate architecture. The corporate architecture includes all software used internally or externally by staff and customers; all hardware components used to process, store, or transmit data; and each API used to connect the corporation to various servers and external partners.
When producing the interview questionnaires, do not oversimplify by asking broad questions like the following:
- Is the customer information secure?
- How many attackers are targeting the network during regular business hours?
- What is the acceptable level of risk to our customer records?
- What is the probability that our company is currently under attack?
In all probability, question 3 will be answered with the word "none." That is not an adequate answer, nor is it reasonable. Answering "yes" to question 1 demonstrates ignorance. Risk is a level that is measured through qualitative and quantitative means. Two quantitative measures commonly used are "Risk = Likelihood x Impact" and "Risk = Threats x Vulnerabilities." It should be noted that determinations of likelihood can be too subjective without known metrics. Just remember that blanket questions similar to the ones above will not produce useful answers until the network has been fully vetted and redesigned.
By understanding risks, you have an opportunity to ensure that you can sufficiently answer all four of the above questions. For instance, once you have a better understanding of the architecture, you might answer the first question with a response like, "The customer data is stored, transmitted, and processed in a manner that mirrors NIST best practices. The data resides in a network that has been designed with real-time detection and response capabilities to generate notifications of ambiguities in the normal processing of data."
Threat Model
The next step in this process is to produce a threat model of the attack surface. A threat model consists of the system that can be attacked (attack surface) and the assets that may be compromised. It is a visually detailed picture that describes who is going to attack you, what the attacks are, the possible outcomes or consequences of each attack, and the risk of each attack. There are tools available on the Internet that can assist with modeling threats, but it may be just as easy to begin with a basic spreadsheet that outlines the attack surface as described above. This can be a laborious process unless you are able to utilize the design documents and the information gathered from the interviews.
Penetration Testing and Source Code Analysis
Other steps to an architectural risk assessment include penetration testing and source code analysis. When conducting penetration testing (runtime analysis), do not just rely on automated tools to produce the results. It is important to build scripts that can emulate some of the attacks you have developed through threat modeling. Let the automated scanner find customary threats and script less evident ones based on the threat model. There are automated source code analysis tools that can be used when applications have too many lines of code for a hands-on review approach. From experience, an expert in a development language can review 5,000-8,000 lines of code per day. Regardless of how vulnerabilities are discovered, update your threat model when new attacks are formed or when new applications are added to your network.
IDENTIFYING VULNERABILITIES AND THREATS
There is no certain way to prepare for every type of cyber attack. Vulnerabilities can be accounted for, but new types of an attack are the proverbial "unknown knowns." Before developing a strategy of threat analysis or even the questionnaires for the employees, you will need to understand the factual information of your business from a technological perspective. To do this, it will be important to understand the nomenclature of attacks, vulnerabilities, and threats.
Vulnerabilities are not threats. A simplified example in a healthcare office might be as follows. A front desk representative momentarily walks away from a logged-in computer. The vulnerability that exists is an authenticated (logged-in) computer that is left unguarded. The threat is that data can be extracted, and this might come in many forms, including that of an unauthorized person who uses the wireless keyboard to access, modify, or delete data. Regardless of the authority the employee has on the network, data can be extracted. The method of extraction is the attack. A risk is the likelihood of an attack on a vulnerability, and this is something that can be both measured and communicated.
The previous example demonstrates a simplified threat. Suppose now that the employee at the workstation was very good about locking her computer but also has the ability to log into an online cloud storage website. This employee has the ability to take protected health information (PHI) data at will and upload it to a different location. In this case, it is not just the inside worker, but the Internet browser itself that poses a risk to the corporation. If the workstation is connected to the Internet, even when it is locked, there is a verifiable risk to the business and PHI. Until there is a better understanding of the architectural risks, there will be a high likelihood that neither the employee nor the office network will be able to predict Internet-based attacks. The larger issue is that business risks are mirrored with technological risks -- and technological risks will affect the business.
A starting point toward identifying risk-based defenses is to create a quick spreadsheet that associates potential points of entry with levels of risk. Deconstruct each level of risk into multiple entry points and remember that an entry point can contain multiple vulnerabilities. Table 1 provides one example, yet the level of risk and defensive measures are options that can only be determined by the corporation developing the spreadsheet.
Table 1 -- Identifying Potential Points of Entry with Levels of Risk
Another useful visual is one that illustrates the relationships between business risks and technical risks (see Table 2). When developing this visual, it is important to include enough employees to cover any direct access to each workstation, server, and database. As stated earlier, these persons on your staff truly know the process side of your business.
Table 2 -- Identifying the Relationships Between Business Risks and Technical Risks
Once you have outlined the above information, conducted assessments, and implemented new security measures, it will be important to retest the security that is now in place. It is also important to provide milestones toward achieving any recommended changes. This is a process that should be analyzed, managed, tested, and documented on a regular basis.
SUMMING UP
A corporate information security strategy will advance the understanding of risk management. It can bring with it a sense of security to the shareholders and corporate governance. When producing an architectural assessment, there should be a strategy that includes a management team responsible for operating procedures and a technical team to oversee the security efforts. These efforts include training, education, and implementation. Whether big or small, all organizations should have one primary individual who can direct the support, implementation, and deployment of information security.
Well-designed corporate networks will not look similar, but they can be developed with the same attributes required to securely store, process, and transmit information. Most businesses do not work within a $100 billion market cap, yet each corporation should be designed with the same determinant principle -- a principle that states, "The protection of client data has been implemented, and risks are minimized to an acceptable level." Although the definition of an "acceptable level" will be subjective, it is an appropriate way of describing a rigorous security architecture and allows senior management to communicate a realistic approach to data security.
ENDNOTE
1 Diermeier, Daniel, and Mathieu Trepanier. "Measuring Reputation." Kellogg School of Management, Northwestern University, February 2009.
