Reading Security-Related Articles by Experts

You don’t have enough time to research every potential source of security threats. Of course, you could hire your own team to help out, but you need to consider the availability of security experts that write for the trade press magazines as a good second choice. These experts tend to spend most of their time enmeshed in security issues, so they know all the ins and outs of the various threats. For example, Jeremy Kirk recently revealed that, “Even Encrypted Medical Record Databases Leak Information”. It’s the sort of article that you need to pay attention to because most businesses rely on databases to store information and the databases that store sensitive information normally rely on encryption of some sort. The kind of article to look for has these characteristics in common:

• A clear title that lacks sensational language (as much as this is possible, anyway)

• A short overview of the problem so that you can decide whether the threat requires further research

• Short descriptions of the methods hackers employ to use the hack

• Links to additional information so you don’t spend hours just looking for the details

• Statistics on the effect of the threat (making it possible for you to assess the risk to your organization more intelligently)

• Case study examples that demonstrate the viability of the attack against a real-world target

Scanning the article takes a few seconds, but by looking for these characteristics, you can usually save yourself from reading an article that really doesn’t tell you anything. The important thing is to get the information you need without wasting a lot of time doing it. After a while, you begin to know which trade press authors best suit the needs of your business and you start paying more attention to the articles they write—saving you additional time. (Likewise, you figure out which authors write articles that are a total waste of your time and disregard them more often than not.)

The best reason to use trade press articles to locate information about security threats is that you can get information on a lot of threats in an incredibly short time. Just scanning for the kinds of clear headlines by authors you know makes it possible to locate the most important threats in just a few minutes.

The main disadvantage of using trade press articles is a lack of depth and the need to watch for writing that is less informative than it could be. You want to be sure that you rely heaviest on authors who provide you with links to the details you need to know everything you can about a threat without having to spend hours looking for it. If you start to find that the trade press article is getting into too much depth, you have a good reason to suspect that it might be more about selling products to you than informing you. Always look for the short, informative article with lots of links.

Checking Security Sites

Security sites tend to provide you with detailed information for a wide range of security threats. The security site may not discuss every current threat, but you can be sure of finding most of the threats that are currently active (and probably a history of all of the threats that security professionals have destroyed in the past). In fact, the sheer weight of all that information makes security sites a bad choice for your first visit. What you really want to do is create a list of threats to research and then visit the security sites to look for those particular threats.

Not all security sites are created equal—a fact that is lost on many people who cruise the Internet looking for security information. In fact, security sites come in four different forms (summarized in Figure 16-1), each of which has its own advantages and disadvantages:

Organization-based sites

Organization-based sites often provide the most concentrated information in a particular area, but lack the breadth of information that other kinds of sites support. For example, the SANS Institute provides you with phenomenal research sources. It also sponsors various kinds of training events. This particular organization (like many others) is vendor supported, but at least you don’t get a single vendor’s perspective of how you should work through security issues.

Government-supported sites

These sites are obviously biased toward the needs of the government that sponsors them, but they’re mostly unbiased in the kinds of information they provide. These sites are good places to locate information about current threats of an international nature. Sites such as the United States Computer Emergency Readiness Team (US-CERT) and National Vulnerability Database provide you with an abundance of useful tips and publications that you can obtain without cost.

Community-supported sites

Of the security sites you can visit, community-supported sites can prove the most interesting. They often offer insights you won’t find anywhere else. Like every other site you visit, they do have an agenda of some sort and this agenda biases the information you receive, but the bias usually isn’t strong enough to affect the quality of the information you receive. Sites such as Vmyths can help you avoid the hysteria that normally comes with security incident disclosures.

Vendor-based sites

When you visit a vendor-based site, you often obtain a depth of information unparalleled by any other source, partially because the vendor wants to impress you. However, because the vendor is also actively engaged in trying to thwart various security threats, you can also gain better insights into what you need to do to prepare for a particular threat. Sites such as Symantec Security Response make it possible to ascertain things like the current threat level on the Internet quickly and determine which threats present the greatest potential for problems for most people.

Figure 16-1. Choosing the correct security threat source is important

Some sites specialize in consolidating information from other sources. For example, Security Focus, Open Source Vulnerability Database (OSVDB), and Common Vulnerabilities and Exposures (CVE) provide indexes of information also found on other sites. Using a consolidated site can save you time, but also makes it possible that you’ll miss an important security notice because the site owner has a bias that is different from the needs of your organization.

An important thing to consider is that you really only need to visit a security site when you feel there is a security threat you need to research. Otherwise, your time is better spent looking for overviews of security threats you might need to deal with. Make sure you visit the kind of site that will best serve your needs for a particular threat. For example, an international threat perpetrated by one country against another will likely receive the best coverage on a government-supported site. Hackers who are trying to extort funds from you after encrypting your hard drive data are often detailed better at vendor-based sites. If you feel that a threat is likely pure hoax, make sure you visit a community-supported site first to verify it.

Getting Input from Consultants

All of the sources discussed so far in the chapter have one thing in common—they provide general information supported by an outside source. However, your business isn’t a general entity and has specific security needs based on the kinds of applications you run, the environment in which you run them, and the level of training your users have. In some cases, the general sources don’t provide enough information because they simply can’t provide it—the authors of those bits of information know nothing about your organization. In this case, you usually need to employ the services of a consultant to consider the security threats.

A consultant can provide specific information about the specific threats faced by your organization in particular. The advice will make it possible to deal with the threats a lot faster than if you had to create a strategy of your own. Of course, the quality of the information comes with a price. Using a consultant is also the most expensive way to deal with security threats. For the most part, the majority of the sources provided in this chapter offer some level of free support. It’s best to use consultants when:

• You already know that the threats are serious

• You can’t create a strategy to handle them quickly

• The methods required for handling the threats are outside the realm of skills your organization has to offer

• Handling the threats requires coordination between several groups or contact with other companies

• There is some other mitigating circumstance that makes handling the security threat yourself untenable

Anticipating Situations that Require No Action at All

Whenever you read about a security threat and research its implications, you need to keep in mind that the documentation you read will make the threat sound dire. And the threat is, in fact, dire for someone. However, the threat may not matter at all to you. Organizations often spend time and money reacting to threats that don’t pose any sort of problem for them. In short, they buy into the hysteria that surrounds security threats when there isn’t any need to do so. One of the things you need to consider as you review current security threats is whether they actually do apply to you. In many cases, they don’t apply and you don’t need to do anything about them. You can blithely slough them off without another thought.

Of course, the problem is in getting to the point where you know the threat doesn’t affect you. A missed threat represents a serious problem because it can open you to attack and the things that follow (such as a downed site or breached data). Assessing the potential risk of a particular security threat involves:

• Determining whether you use the technology described as the entry point for the security threat

• Considering whether the kind of access required to invoke the threat actually applies to your organization

• Defining the circumstances under which your organization could be attacked and when the attack might occur

• Reviewing the safeguards you currently have in place to determine whether they’re sufficient to thwart the attack

• Ensuring that you have a strategy in place should the attack occur and you’re wrong about the hacker’s ability to invoke it on your organization

Deciding Between an Upgrade or an Update

Chapter 13 and Chapter 14 discuss naturally occurring upgrades and updates. However, in this case, you’re thinking about an upgrade or an update due to a security threat. Many of the same rules apply. An upgrade always indicates some type of significant code change, while an update may not require a code change at all, but may instead reflect a change in user interface or some other element that you can change quickly without modifying the underlying code. Consequently, the first demarcation between upgrades and updates are those that you normally apply when making any other change.

A security threat can change the intention and urgency of an upgrade or an update. In some cases, you need to tackle the problem in several parts:

1. Address the specific issue that the security threat focuses upon as an update.

2. Upgrade or update any supporting software (such as firewalls or the operating system) to ensure the security threat can’t attack the application from another direction.

3. Train users to avoid performing tasks in such a manner that they provide hackers with valuable information or access that the hacker can use to initiate the attack.

4. Modify any code surrounding the target code to ensure the application continues to work precisely as designed as an upgrade after you’ve deployed the update.

5. Perform an upgrade of any dependencies to ensure the entire application is stable.

6. Verify that the upgraded application continues to thwart the security threat by performing extensive testing targeted in the same manner that a hacker would use.

Not every security threat requires this extensive list of steps to overcome, but it’s important to consider each step when deciding how to proceed. You may find that just an update will suffice to thwart the attack or that an operating system upgrade is really all you need. The point is to consider every possible aspect of the security threat in relation to your application and its supporting data.

Sometimes you really do need to make quick decisions regarding the use of an upgrade or an update to fix a security threat. The steps in this section are certainly helpful, but the flowchart in Figure 16-2 provides an even faster method of making the determination.

Figure 16-2. Making the decision between upgrade and update quickly is sometimes necessary

Defining an Upgrade Plan

Chapter 13 describes the process for a standard upgrade for your application. It details a process that could require months to complete. Of course, you have time when you’re performing an upgrade of your application to perform every task carefully and completely. Security threats seldom wait long enough to provide you with months of waiting time to create an upgrade and deploy it. The only way that you obtain the level of advance warning to perform a long-term upgrade is to have someone in the right place to obtain information when it first becomes available (many ethical hackers give vendors three months to a year to fix problems before making them public knowledge).

When working through an upgrade in response to a security threat, you need to consider methodologies that allow you to create the upgrade and test it incrementally as you work in order to deliver the upgrade in a shorter timeframe. Agile programming techniques can help you accomplish this task. Of course, if your organization doesn’t normally use agile programming techniques, the time lost in learning them won’t help much. Even so, part of your upgrade plan should include some methodology for creating the code and testing it on a much shorter schedule than is normal. After the threat has passed, you need to go back through the code and ensure you didn’t introduce yet more security holes in fixing the hole presented by the security threat.

In Chapter 14, “Performing Emergency Updates” discusses the need for a fast response team. In many cases, using this team to put the upgrade together will save time and possibly expense. The team is already used to working together to create updates quickly. Using it to create an upgrade in response to a security threat makes sense. However, you need to ensure that the team has the proper staffing to handle an upgrade. It may become necessary to add team members to provide services beyond those normally required for an update.

Verifying Updates Address Threats

The focus of this chapter is on speed of execution. When you identify a security threat, you need to act upon the information as quickly as possible. Consequently, an update is the preferred method of attacking the problem because updates require less time, fewer resources, and potentially cause fewer issues during testing. In this case, updates mean more than simply your application. Updates can include:

• Adjustments to the security software already in place

• Alterations of the host platform

• Modifications of the host browser

• Changes in procedure based on user training or other means

• Updates to the underlying application through noncoded or lightly coded means

• Modification of dependent software such as libraries, APIs, and microservices

Unfortunately, updates don’t always fix the problem. If the goal is to thwart a security threat, then finding the correct course of action first is the best way to proceed because time you waste trying other measures will simply delay the approach that works. The hackers aren’t waiting. Sometimes speed of execution comes down to performing more detailed fixes and simply admitting that you need more time than is probably convenient to effect a repair.

The crux of the matter is to look at the kind of attack that the hacker uses. For example, a man-in-the-middle attack may simply require that you encrypt incoming and outgoing data correctly and with greater care. In addition, it would require additional authentication and authorization measures. A hack of this sort isn’t easily fixed using an update because you’re looking at the way in which data is prepared, sent, and processed, which are three tasks that the underlying code must perform.

On the other hand, a distributed denial-of-service (DDoS) attack does lend itself to the update model because you can change the security software settings, provide additional system resources, and reconfigure the platform to make such an attack harder. You can also fix social engineering hacks through user training, modification of the user interface, and changes to the application’s security settings. The kind of attack determines whether an update is a good choice. In many cases, you find that you can at least reduce the likelihood of an attack through an update, but may not be able to fix it completely.

Determining Whether the Threat Is an Emergency

When talking about security threats, it’s important to make a determination of whether the threat presents an emergency. Chapter 14 discussed the criteria for an emergency from a general update perspective. Here are some things to consider in addition to the general considerations when working through security threat issues:

• Any zero-day security threat that actively targets your system or application

• Any in-progress attack

• Significant, verifiable threats delivered directly to the organization or one of its staff

• Attacks against libraries, APIs, or microservices that your application depends upon

Defining an Update Plan

Chapter 14 defines the requirements for an update plan. When working through an update that addresses a security threat, you want to use the fast response team to ensure the update is completed and tested in a timely manner (see “Creating a Fast Response Team” in Chapter 14). It’s also important to ensure that you consider the same sorts of issues discussed in “Defining an Upgrade Plan”. For example, using agile programming techniques will only make things go faster and reduce the time required to obtain a good update.

Asking for Updates from Third Parties

Something that many development teams forget in the rush to get a security update out the door is the need to address dependencies. If the dependent code is rock solid and you’re using the latest release, you might not have to check into an update immediately, but you do need to make the third party aware of potential security issues with their product and ask that these problems be addressed. Otherwise, any fixes you create might not continue to work—the hacker will simply choose another avenue of attack.