New DISA Cyber Tools

For those of you who do cyber work in the U.S. Department of Defense (DoD) arena, the Defense Information Systems Agency (DISA) has released a series of new Service Product packages to assist in the Risk Management Framework (RMF) process. 

Each Service Product package contains Control Correlation Identifiers (CCI), to assist users in breaking down high-level policy framework requirements and associated them with low-level security settings to determine compliance with the objectives of specific Security Controls.  If that sounds like another language to you, chances are you can safely ignore this new resource.  If you're working on RMF packages and you're familiar with CCIs, you won't want to pass this one up.

For more information about Service Product packages, visit DISA’s Risk Management Framework customer portal (Common Access Card required).

Meltdown and Spectre

With the Equifax Inc. breach still visible in our rearview mirror, we didn’t expect to be discussing another massive cyber vulnerability quite so soon. But two recently-discovered processor flaws called Meltdown and Spectre may have implications that are far more widespread and serious. The Equifax debacle affected roughly half of the adults in the United States. Between them, Meltdown and Spectre affect the processors of nearly every computer, tablet, smartphone, and cloud computing service in current use. Virtually every person, business, military, and government agency in the world is a potential victim.

How did this happen?

Both vulnerabilities can be traced back to our civilization’s ever-growing demand for faster computers. We want (and expect) each generation of information technology devices to be noticeably quicker than its predecessors. In an attempt to satisfy the continual demand for greater speed, manufacturers of processors began relying on a technique known as “speculative execution.” In simple terms, a processor tries to guess which code instructions will be needed next, and then fetches the “speculative” code from memory to have it ready at the instant its required. When the processor’s guess turns out to be wrong, it needs to flush the speculated code and then load the correct code before proceeding.

Meltdown, which is specific to Intel chips, exploits the way speculative executions are stored in a processor's cache. Essentially, it develops a model of what’s currently loaded in the processor by digging through the processor's trash, and then uses that model to reconstruct parts of the computer's high-privilege memory, including passwords and sensitive personal information.

By contrast, Spectre, directly exploits the process of speculative execution. A Spectre attack fools a target processor into speculatively executing code sequences that should not be active during correct program execution. This can force even the most secure applications to render up protected information.

Every processor manufacturer implements speculative execution in its own (usually proprietary) fashion. As a result, a Spectre exploit which affects one set of processors may not be effective against another set of processors. This makes Spectre far more difficult to execute than Meltdown, but also far more difficult to prevent or repair.

What’s at risk?

Basically, everything. Make no mistake. Top level industry analysts believe this represents a global failure of computer security at the fundamental level. As of this writing, no hostile exploits of either flaw are known to exist. But the weaknesses are now public knowledge, so it’s only a matter of time until hackers and other hostile actors figure out a way to capitalize on the vulnerabilities.

What’s the fix?

Software patches for Meltdown are already available for Windows, most supported versions of Linux, and other operating systems. Unfortunately, these patches can slow down computers by 20 to 30 percent. Clearly, this will have implications for processing speeds, download speeds, and all online services for the foreseeable future.

A resolution for Spectre is less easily obtained. The flaw affects nearly all microprocessors on the market, and according to Google Project Zero (the security research group who discovered both weaknesses), a fix for Spectre may require the development and fielding of an entirely new generation of processor chips.

Links:

Apple says all iPhones, iPads, and Macs are affected.

Intel Whitepaper on partial mitigation.

US CERT statement on Meltdown and Spectre Side-Channel Vulnerabilities.

The KRACK Attack

Unless you've been living under a rock for the past several weeks, you've probably heard about the KRACK wireless vulnerability (Key Reinstallation AttaCK) that’s present in ALL unpatched Wi-Fi systems.

The exploit takes advantage of design or implementation flaws in Wi-Fi Protected Access II (WPA2) cryptographic protocols to reinstall a key that’s already in use, allowing attackers to eavesdrop on some or all data transmitted or received over a Wi-Fi connection. If your network is not patched against this vulnerability, hackers have basically got the keys to your kingdom.

What you need to know:

With the exception of certain military-grade specialty devices, all Wi-Fi capable devices are affected. The severity of the impact varies, depending on your operating system, confidentiality protocol, and the handshake type used by your network. Some configurations allow the attacker to replay and decrypt some traffic. Other configurations permit the attacker to replay and decrypt all traffic, as well as injecting arbitrary packets.

What can you do?

The National Security Agency has published a list of five recommended mitigations.

1. Install patches to both the clients and Access Systems as soon as they are made available.  Relevant CVEs: CVE-2017-13077, CVE-2017-13078, CVE-2017-13079, CVE-2017-13080, CVE-2017-13081, CVE-2017-13082, CVE-2017-13084, CVE-2017-13086, CVE-2017-13087, and CVE-2017-13088.
2. Disable Fast BSS Transition on Access Systems until patches are available to prevent the FT handshake attack.
3. Temporarily use only AES-CCMP until patches are available.
4. Install an underlying virtual private network until patches are available.
5. Do not use modes requiring generation of a Peerkey.

We'll provide more updates as they become available.

Listen to this...

Steve Gibson’s Security Now Pod Cast; https://www.grc.com/securitynow.htm

Network Protection (Part 2)

In Part 1 of this post, we presented a series of questions to stimulate your thought processes about ways to better protect your data.  Here are a few more questions to add to that list…

#4  Do you know where your network data is traveling (internally and externally)?

If you’re not already using a good Network Monitoring Tool, it’s time to invest in one.  You need to clearly capture all potential points of data infiltration and exfiltration.  You need to know precisely how data flows through your network, routing, direction of flow, processing delay, queuing delay, transmission delay, propagation delay, and any other factor that can affect data integrity and/or throughput.

#5  How do your users behave?

Behavior analysis can play a major part in the success/failure of any security program.  If you don’t understand how your users interact with the network, it can be difficult or impossible to create effective access controls and security policies.  If you have a solid feeling for the needs and habits of your typical users, you can implement technical and procedural controls to maintain good network hygiene while minimizing impact to accomplishment of your organization’s goals.

Of equal importance, a thorough understanding of typical user behavior can make it much easier to spot atypical user behavior.  This can be key to identifying users who might pose an insider threat to your network.

#6  Are your control mechanisms tailored to the sensitivity and importance of the data they’re protecting?

It can be tempting to adopt an across-the-board approach to security measures.  Everything receives the same level of protection, monitoring, and general effort.  This kind of doctrinaire thinking may simplify the selection and configuration of defensive mechanisms, but it can result in unnecessary expense and reduction in productivity.

Think of your security measures like Secret Service Agents.  It makes perfect sense to invest major time, effort, and money into protecting the safety of the president.  That same level of protection for a deputy assistant cabinet secretary would be wasteful.  Extending similar protection to a pastry chef in the White House kitchens would be ludicrous.  All three of these positions (president, deputy assistant secretary, and pastry chef) are government employees, but they do not require the same kind of protection.  In fact, the pastry chef might find it impossible to do his/her job while continually surrounded by an armed protection detail.

Sensitive information, intellectual property, and similarly vital types of data need all the protection you can provide.  Non-sensitive data that’s easily replicable (or freely available from other sources) simply doesn’t require the same level of protection.  That’s not to suggest that operating systems and software on less sensitive network components should not be properly patched and configured.  You can’t allow weak spots in your ACLs, firewall policies, and other defensive measures.  But non-sensitive data doesn’t necessarily need high-end encryption, real-time backups, high-priority restoration mechanisms, or many of the other measures employed to defend sensitive materials.

Network Protection (Part 1)

When someone brings up the topic of network protection, what’s the first thing that pops into your head? Is it passwords or encryption? Does your mind go to Wi-Fi Protection Access 2 (WPA2)? Or do you think about LAN separation, physical security measures, DMZs, compensating controls, and complex architecture?

There obviously can’t be one answer that’s right for everyone. Two organizations of similar size and complexity may have very different requirements based on their internal cultures, operating models, budgets, policy obligations, and a multitude of other factors. The security implementation for individual networks can vary drastically based on the level of Confidentiality, Availability, and Integrity required by the data traversing the network.

Think of this post as an intellectual exercise—an opportunity to raise questions and stimulate your thought processes about ways to better protect your data. Without knowing the specifics of your network, we can’t offer nuts and bolts details for improving your security posture, but we can ask a few questions that will (hopefully) help you get your mindset in the right place.

The questions themselves are straightforward and deceptively simple.  Don't let that fool you.  Finding answers to some of them may be murky and difficult.

#1 Do you know what devices are present on your network?

We don’t mean according to your hardware list and network drawings. We mean actual devices (whether planned or unplanned) that are operating on your network. Even with relatively stiff access control measures, if you have multiple administrators, there’s a fair chance that one (or more) of them have authorized connections to devices that aren’t part of your planned network. It’s amazing how often such on-the-fly additions don’t get properly documented, even when they’re added for constructive purposes by users/administrators with only good intentions.

If you don’t know exactly what’s on your network, odds are good that some of the devices are not being scanned, patched, audited, or properly monitored. And that means you’ve got vulnerabilities and potential attack surfaces that you’re not even aware of.

Regardless of the size of your network, you should have full visibility of every connected device. Common security measures like reoccurring scanning policies, regularly scheduled firewall reviews, white/black lists, and Access Control Lists are all helpful, but one rogue device added by a well-meaning administrator can create a gaping hole in your defenses.

#2 Does your vulnerability management solution keep your security patches current?

If your cyber team is on the ball, you may be nodding your head and patting yourself on the back right now. But pause in mid-pat for a second and look back to Question #1. Even if you’ve got a rock solid process for downloading, testing, and pushing security patches, it’s only truly effective if it covers everything on your network. This is one of the places where unknown device(s) can really bite you. If you don’t know it’s there, you’re definitely not patching it.

#3 Does your access control strategy balance network security against availability and the needs of users?

Again, there is no one-size-fits-all solution. The campus network at a university may be large, general-purpose in nature, and might support a user base in which hundreds of people come and go more or less continually. Except for isolated modules protecting Personally Identifiable Information, grades, etc., much of the network’s content is likely to be relatively non-sensitive. Users may share passwords without risking major consequences. Loss of network functionality would no doubt be a significant inconvenience, but would probably not qualify as an emergency.

By contrast, a military network might have a small number of users whose account access and credentials must be rigidly controlled. The content is likely to be more narrowly focused, will tend to be sensitive in nature, and may actually be classified to protect national security. The sharing of passwords and credentials could be punishable under criminal law. Loss of network functionality can lead to degradation of mission readiness, and could—under some circumstances—actually get people killed.

Getting your access control strategy right can be a complex process. Implementation should be aligned to the size of your user base, the sensitivity of the network’s content, and the consequences of losing functionality. If you’re using a turn-key access control solution that doesn’t take these things into account, you may be drastically under protecting (or over protecting) your network.

Continued in Part 2…

Equifax Update

Details of the recent EquifaxInc. breach are continuing to emerge.  We now know that the intrusion was accomplished by exploiting the Apache Struts web vulnerability (CVE-2017-5638), which allows remote attackers to execute arbitrary commands via a #cmd= string in a crafted Content-Type HTTP header. 

A security patch for the flaw in the open source Apache Struts 2 framework was available as early as March 6th, more than two months before the Equifax hack began.  So far, Equifax representatives have declined to answer questions about why this known vulnerability went unpatched for so long.  The fix is known to be complex and labor intensive, which may have contributed to the delay in closing the security hole in Equifax web servers and applications.

Difficulty aside, it now seems clear that the Equifax breach—which impacted nearly half of the adults in the United States—was entirely preventable.

On September 15th, Equifax announced that the company’s Chief Security Officer, Susan Mauldin, and its Chief Information Officer, David Webb, were retiring “effective immediately.” 

Pulling the Plug on Kaspersky

The Department of Homeland Security has issued Binding Operational Directive 17-01, ordering all federal departments and agencies to discontinue use of any software made by the Russian cybersecurity firm Kaspersky Lab.  According to the directive, DHS is “…concerned about the ties between certain Kaspersky officials and Russian intelligence and other government agencies…,” as well as “…requirements under Russian law that allow Russian intelligence agencies to request or compel assistance from Kaspersky…”

The directive gives all federal branches 30 days to identify and report the presence of any Kaspersky product on government information systems and networks, followed by an additional 30 days to develop detailed plans for removing all software produced by the company.  The process of ensuring full deletion is expected to take a further 30 days.

If all goes as planned, all traces of Kaspersky software should be purged from U.S. government IT assets no later than 90 days after issuance of the directive.

The announcement comes in the wake of persistent rumors about the company’s alleged links to the Kremlin.  While solid proof of these allegations hasn’t (yet) been made public, we do know that the company's founder, Eugene Kaspersky, is a former Russian intelligence officer, as are several other key employees of the company.

Kaspersky representatives have fervently denied any such connections to the Kremlin.

The current DHS ban only applies to civilian branches of government, but Senator Jeanne Shaheen (D-N.H.) is spearheading an effort to extend the ban to the Department of Defense and any elements of the government not already subject to Binding Operational Directive 17-01.  Calling the directive "a significant step forward," Senator Shaheen added that, “the strong ties between Kaspersky Lab and the Kremlin are very alarming."