Another Word For It Patrick Durusau on Topic Maps and Semantic Diversity

If you remember my posts, “Cybersecurity Sprint or Multi-Year Egg Roll?” from last June (2015), and Fed Security Sprint – Ans: Multi-Year Egg Roll (Nov. 2015), there is further confirmation of the projected duration of the egg roll from the GAO.

The GAO report, DHS Needs to Enhance Capabilities, Improve Planning, and Support Greater Adoption of Its National Cybersecurity Protection System

The executive summary prepares the reader for 61 pages of grim reading:

The Department of Homeland Security’s (DHS) National Cybersecurity Protection System (NCPS) is partially, but not fully, meeting its stated system objectives:

• Intrusion detection: NCPS provides DHS with a limited ability to detect potentially malicious activity entering and exiting computer networks at federal agencies. Specifically, NCPS compares network traffic to known patterns of malicious data, or “signatures,” but does not detect deviations from predefined baselines of normal network behavior. In addition, NCPS does not monitor several types of network traffic and its “signatures” do not address threats that exploit many common security vulnerabilities and thus may be less effective.
• Intrusion prevention: The capability of NCPS to prevent intrusions (e.g., blocking an e-mail determined to be malicious) is limited to the types of network traffic that it monitors. For example, the intrusion prevention function monitors and blocks e-mail. However, it does not address malicious content within web traffic, although DHS plans to deliver this capability in 2016.
• Analytics: NCPS supports a variety of data analytical tools, including a centralized platform for aggregating data and a capability for analyzing the characteristics of malicious code. In addition, DHS has further enhancements to this capability planned through 2018.
• Information sharing: DHS has yet to develop most of the planned functionality for NCPS’s information-sharing capability, and requirements were only recently approved. Moreover, agencies and DHS did not always agree about whether notifications of potentially malicious activity had been sent or received, and agencies had mixed views about the usefulness of these notifications. Further, DHS did not always solicit—and agencies did not always provide—feedback on them.

In addition, while DHS has developed metrics for measuring the performance of NCPS, they do not gauge the quality, accuracy, or effectiveness of the system’s intrusion detection and prevention capabilities. As a result, DHS is unable to describe the value provided by NCPS.

Regarding future stages of the system, DHS has identified needs for selected capabilities. However, it had not defined requirements for two capabilities: to detect (1) malware on customer agency internal networks or (2) threats entering and exiting cloud service providers. DHS also has not considered specific vulnerability information for agency information systems in making risk-based decisions about future intrusion prevention capabilities.

Federal agencies have adopted NCPS to varying degrees. The 23 agencies required to implement the intrusion detection capabilities had routed some traffic to NCPS intrusion detection sensors. However, only 5 of the 23 agencies were receiving intrusion prevention services, but DHS was working to overcome policy and implementation challenges. Further, agencies have not taken all the technical steps needed to implement the system, such as ensuring that all network traffic is being routed through NCPS sensors. This occurred in part because DHS has not provided network routing guidance to agencies. As a result, DHS has limited assurance regarding the effectiveness of the system.

The brightest part of the report is that DHS “concurred with GAO’s recommendations.”

That’s a far cry from the state of total denial at the Office of Personnel Management last year. DHS is acknowledging its problems. Whether than translates into fixing those problems remains to be seen.

(Do you know the fate of the management incompetents at OPM? Just curious who is being inflicted with their incompetence now.)

I truly hate to say anything nice about the DHS but one must give the devil his due.

Unfortunately for the DHS, elected leaders don’t understand that need, desire, importance, are all non-factors in technical success. You may not like mendelian genetics, but as Stalin discovered, you pursue other models at your own risk.

The same is true for cybersecurity.

Disappointed to read David Bisson advocating security through secrecy in Ransomware author tries to blackmail security researcher into taking down ‘educational’ malware project.

From the post:

The author of the Magic ransomware unsuccessfully attempted to blackmail a security researcher into taking down two open-source ‘educational’ malware projects on GitHub.

Magic, a malicious program which is written in C# and which demands 1 Bitcoin from its victims, is the second strain of ransomware discovered in January to have been built on malware that has been made available to the public for ‘educational’ purposes.

The first threat, Ransom_Cryptear.B, is based on an open-source project called Hidden Tear, which is currently hosted by Turkish security researcher Utku Sen on his GitHub page.

…

Whether Sen is able to recover the victims’ files without working with the ransomware author remains to be seen. However, what is abundantly clear is Sen’s foolishness in releasing ransomware code as open-source. Though such a move might have educational motives at heart, this will not stop malicious and inexperienced attackers from co-opting the ransomware code for their own purposes.

Going forward, researchers should never make ransomware code available beyond the labs where they study it. Ordinary users will surely benefit in the long run.

See David’s post for the details. My concern is his advocacy of non-publication of ransomware code.

McAfee Labs 2016 Threats Predictions report makes it clear that “malicious and inexperienced attackers” are not the source of great concern for ransomware.

…..
In 2015 we saw ransomware-as-a-service hosted on the Tor network and using virtual currencies for payments. We expect to see more of this in 2016, as inexperienced cybercriminals will gain access to this service while staying relatively anonymous.

Although a few families—including CryptoWall 3, CTB-Locker, and CryptoLocker—dominate the current ransomware landscape, we predict that new variants of these families and new families will surface with new stealth functionalities. For example, new variants may start to silently encrypt data. These encrypted files will be backed up and eventually the attacker will pull the key, resulting in encrypted files both on the system and in the backup. Other new variants might use kernel components to hook the file system and encrypt files on the fly, as the user accesses them.
….. (at page 24)

Amateurs aren’t building “ransomware-as-a-service” sites and there’s no reason to pretend otherwise.

Moreover, the “good old boy network” of security researchers hasn’t protected anyone from ransomware if the McAfee Labs and similar reports are to be credited. If concealment of security flaws and malware were effective, there should be some evidence to that effect. Yes?

In the absence of evidence, dare I say “data?,” we should dismiss concealment as a strategy for cybersecurity as utter speculation. Speculation that favors a particular class of researchers. (Can you guess their gender statistics?)

In case you are interested, the Github page for Hidden Tear now reads in part:

This project is abandoned. If you are a researcher and want the code, contact me with your university or company e-mail http://utkusen.com/en/contact.html

Well, no harm done. If you are looking for the master.zip file for Hidden Tear, check the Internet Archive: Wayback Machine, or more directly, the backup of the Hidden Tear project on 26 January 2016.

You can presume that copies have been made of the page and master.zip file, just in case something unfortunate happens to the copies at the Internet Archive: Wayback Machine.

Better software, user education, legal actions against criminals are all legitimate and effective means of combating the known problem of ransomware.

Concealing ransomware code is a form of privilege. As we all know, privilege has an unhappy record in computer programming and society in general. Don’t support it, here or anywhere.

OUCH! Security Awareness Newsletter

From the post:

Wow! This is the first security awareness document that our users really like! Thank you, SANS”

That note came from the CISO of an 8,000 employee organization. OUCH! is the world’s leading, free security awareness newsletter designed for the common computer user. Published every month and in multiple languages, each edition is carefully researched and developed by the SANS Securing The Human team, SANS instructor subject matter experts and team members of the community. Each issue focuses on and explains a specific topic and actionable steps people can take to protect themselves, their family and their organization. OUCH! is distributed under the Creative Commons BY-NC-ND 4.0 license. You are encouraged to distribute OUCH! within your organization or share with family and friends, the only limitation is you cannot modify nor sell OUCH!.

The OUCH! newsletter and all of its translations are done by community volunteers. As such, some languages may not be available upon initial publication date, but will be added as soon as they are. Be sure to review our other free resources for security awareness programs such as presentations, posters and planning materials on our Resources Page.

You probably won’t benefit from this but may know users who will. Fairly commonplace advice.

You can subscribe to the newsletter but must have a SANS account.

Be aware your users may compare your password requirements with those at SANS:

Passwords must be at least 10 characters long and contain 5 unique characters

Passwords must also include at least one of each of the following: number, uppercase letter, lowercase letter, and special character ( ! £ $ % ^ & * ( ) @ # ? < > . )

I suppose that helps but you remember Schneier’s first book on cryptography? In the introduction he says there are two kinds of cryptography. The first kind is the sort that keeps your kid sister from reading your diary. The second kind stumps government sourced agencies. This book is about the latter. Words to that effect.

The SANS passwords will keep your kid sister out, at least to middle school, maybe.

PS: Best name for a newsletter I have seen in a long time. Suggestions for a topic map newsletter name?

Adrian Bridgwater uncovers a cybersecurity version of three card monte in Fortinet on SSH vulnerabilities: look, this really isn’t a backdoor, honest.

Fortinet created an undocumented method to communicate with FortiManager devices. Or in Fortinet’s own security warning:

An undocumented account used for communication with authorized FortiManager devices exists on some versions of FortiOS, FortiAnalyzer, FortiSwitch and FortiCache.

On vulnerable versions, and provided “Administrative Access” is enabled for SSH, this account can be used to log in via SSH in Interactive-Keyboard mode, using a password shared across all devices. It gives access to a CLI console with administrative rights.

In an update to previous attempts at obfuscation, Fortinet says:

As previously stated, this vulnerability is an unintentional consequence of a feature that was designed with the intent of providing seamless access from an authorized FortiManager to registered FortiGate devices. It is important to note, this is not a case of a malicious backdoor implemented to grant unauthorized user access.

Even with a generous reading, Fortinet created a “feature” that benefited only Fortinet, did not disclose it to its customers and that “feature” lessened the security of those customers.

If “backdoor” is limited to malicious third parties, perhaps we should call this a “designed security defect” by a manipulative first party.