Category: Cyber Missions

At the 2018 World Economic Forum, global leaders voiced concerns about the growing trend of cyberattacks targeting critical infrastructure and strategic industrial sectors, citing fears of a worst-case scenario that could lead to a breakdown of the systems that keep societies functioning. A painful example was the May 2017 WannaCry ransomware attack in which a worm rapidly spread through a number of computer networks, affecting more than 150 countries and more than 400,000 endpoints.

One of the largest victims of the WannaCry attack was the National Health Service in England and Scotland, where up to 70,000 computers, MRI scanners, and blood-storage refrigerators may have been affected. In this global threat environment, the need for Computer Security Incident Response Teams (CSIRTs) has become ever more critical. CSIRTs are expert teams that use their specialized knowledge and skills to detect and respond to computer security incidents. In the broader internet community, these teams form a "global network" from a diverse group of organizations and sectors, such as critical infrastructure, government, industry, and academia. In this blog post, the first in a series on CSIRTS, I talk about the work of CSIRTs and their importance in the global threat landscape.

In the first post in this series, I presented 10 types of application security testing (AST) tools and discussed when and how to use them. In this post, I will delve into the decision-making factors to consider when selecting an AST tool and present guidance in the form of lists that can easily be referenced as checklists by those responsible for application security testing.

IPv6 deployment is on the rise. Google reported that as of July 14 2018, 23.94 percent of users accessed its site via IPv6, up 6.16 percent from that same date in 2017. Drafted in 1998 and an Internet Standard as of July 2017, Internet Protocol 6 (IPv6) is intended to replace IPv4 in assigning devices on the internet a unique identity. Plans for IPv6 got underway after it was realized that IPv4's cap of 4.3 billion addresses would not be sufficient to cover the number of devices accessing the internet. This blog post is the first in a series aimed at encouraging IPv6 adoption, whether at the enterprise-wide level, the organizational level, or the individual, home-user level.

In recent days, the VPNFilter malware has attracted attention, much of it in the wake of a May 25 public service announcement from the FBI, as well as a number of announcements from vendors and security companies. In this blog post, I examine the VPNFilter malware attack by analyzing the vulnerabilities at play, how they were exploited, and the impact on the Internet. I also outline recommendations for the next generation of small Internet of Things (IoT) device manufacturers, including home routers, which were the target of VPNFilter malware. Because this post also emphasizes the prioritization of vulnerabilities that have significant or large-scale impact, I will recap recommendations made in the March 2017 blog post on the Mirai botnet.

Bugs and weaknesses in software are common: 84 percent of software breaches exploit vulnerabilities at the application layer. The prevalence of software-related problems is a key motivation for using application security testing (AST) tools. With a growing number of application security testing tools available, it can be confusing for information technology (IT) leaders, developers, and engineers to know which tools address which issues. This blog post, the first in a series on application security testing tools, will help to navigate the sea of offerings by categorizing the different types of AST tools available and providing guidance on how and when to use each class of tool.

See the second post in this series, Decision-Making Factors for Selecting Application Security Testing Tools.

Part one of this series of blog posts on the collection and analysis of malware and storage of malware-related data in enterprise systems reviewed practices for collecting malware, storing it, and storing data about it. This second post in the series discusses practices for preparing malware data for analysis and discuss issues related to messaging between big data framework components.

The growth of big data has affected many fields, including malware analysis. Increased computational power and storage capacities have made it possible for big-data processing systems to handle the increased volume of data being collected. In addition to collecting the malware, new ways of analyzing and visualizing malware have been developed. In this blog post--the first in a series on using a big-data framework for malware collection and analysis--I will review various options and tradeoffs for dealing with malware collection and storage at scale.

As part of an ongoing effort to keep you informed about our latest work, this blog post summarizes some recently published SEI reports, podcasts, and presentations highlighting our work in virtual integration, blockchain programming, Agile DevOps, software innovations, cybersecurity engineering and software assurance, threat modeling, and blacklist ecosystem analysis. These publications highlight the latest work of SEI technologists in these areas. This post includes a listing of each publication, author(s), and links where they can be accessed on the SEI website.

Well-known asymmetries pit cyber criminals with access to cheap, easy-to-use tools against government and industry organizations that must spend more and more to keep information and assets safe. To help reverse this imbalance, the SEI is conducting a study sponsored by the U.S. Office of the Director of National Intelligence to understand cyber intelligence best practices, common challenges, and future technologies that we will publish at the conclusion of the project. Through interviews with U.S.-based organizations from a variety of sectors, we are identifying tools, practices, and resources that help those organizations make informed decisions that protect their information and assets. This blog post describes preliminary findings from the interviews we have conducted so far. Our final report, which will include an anonymized look at the cyber intelligence practices of all the organizations we interviewed, will be released after the conclusion of the study in 2019.

This blog post is also authored by Forrest Shull.

Modern software systems are constantly exposed to attacks from adversaries that, if successful, could prevent a system from functioning as intended or could result in exposure of confidential information. Accounts of credit card theft and other types of security breaches concerning a broad range of cyber-physical systems, transportation systems, self-driving cars, and so on, appear almost daily in the news. Building any public-facing system clearly demands a systematic approach for analyzing security needs and documenting mitigating requirements. In this blog post, which was excerpted from a recently published technical report, we present the Hybrid Threat Modeling Method that our team of researchers developed after examining popular methods.

Almost 30 years ago, the SEI's CERT Coordination Center established a program that enabled security researchers in the field to report vulnerabilities they found in an organization's software or systems. But this capability did not always include vulnerabilities found on Department of Defense (DoD) sites. In 2017, the SEI helped expand vulnerability reporting to the DoD by establishing the DoD Vulnerability Disclosure program. This blog post, which was adapted from an article in the recently published 2017 Year in Review, highlights our work on this program.

As the use of unmanned aircraft systems (UASs) increases, the volume of potentially useful video data that UASs capture on their missions is straining the resources of the U.S. military that are needed to process and use this data. This publicly released video is an example of footage captured by a UAS in Iraq. The video shows ISIS fighters herding civilians into a building. U.S. forces did not fire on the building because of the presence of civilians. Note that this video footage was likely processed by U.S. Central Command (CENTCOM) prior to release to the public to highlight important activities within the video, such as ISIS fighters carrying weapons, civilians being herded into the building to serve as human shields, and muzzle flashes emanating from the building.

This post is also authored by Matt Sisk, the lead author of each of the tools detailed in this post (bulk query, autogeneration, and all regex).

The number of cyber incidents affecting federal agencies has continued to grow, increasing about 1,300 percent from fiscal year 2006 to fiscal year 2015, according to a September 2016 GAO report. For example, in 2015, agencies reported more than 77,000 incidents to US-CERT, up from 67,000 in 2014 and 61,000 in 2013. These incident reports come from a diverse community of federal agencies, and each may contain observations of problematic activity by a particular reporter. As a result, reports vary in content, context, and in the types of data they contain. Reports are stored in the form of 'tickets' that assign and track progress toward closure.

This blog post is the first in a two-part series on our work with US-CERT to discover and make better use of data in cyber incident tickets, which can be notoriously diverse. Specifically, this post focuses on work we have done to improve useful data extraction from cybersecurity incident reports.

In a previous post, I discussed the Pharos Binary Analysis Framework and tools to support reverse engineering of binaries with a focus on malicious code analysis. Recall that Pharos is a CERT-created framework that builds upon the ROSE compiler infrastructure developed by Lawrence Livermore National Laboratory for disassembly, control flow analysis, instruction semantics, and more. Pharos uses these features to automate common reverse engineering tasks. I'm pleased to announce that we've updated our framework on GitHub to include many new tools, improvements, and bug fixes. In this post, I'll focus on the tool-specific changes.

When I was pursuing my master's degree in information security, two of the required classes were in cognitive psychology and human factors: one class about how we think and learn and one about how we interact with our world. Students were often less interested in these courses and preferred to focus their studies on more technical topics. I personally found them to be two of the most beneficial. In the years since I took those classes, I've worked with people in many organizations in roles where it is their job to think: security operations center (SOC) analysts, researchers, software developers, and decision makers. Many of these people are highly technical, very intelligent, and creative. In my interactions with these groups, however, the discussion rarely turns to how to think about thinking. For people whose jobs entail pulling together and interpreting data to answer a question or solve a problem (i.e. analyze), ignoring human factors and how we and others perceive, think, and remember can lead to poor outcomes. In this blog post, I will explore the importance of thinking like an analyst and introduce a framework to help guide security operations center staff and other network analysts.

The crop of Top 10 SEI Blog posts in the first half of 2017 (judged by the number of visits by our readers) represents the best of what we do here at the SEI: transitioning our knowledge to those who need it. Several of our Top 10 posts this year are from a series of posts on best practices for network security that we launched in November 2016 in the wake of the Dyn attack. In this post, we will list the Top 10 posts with an excerpt from each post as well as links to where readers can go for more information about the topics covered in the SEI blog.

As part of an ongoing effort to keep you informed about our latest work, this blog post summarizes some recently published SEI technical reports, white papers, podcasts and webinars on supply chain risk management, process improvement, network situational awareness, software architecture, network time protocol as well as a podcast interview with SEI Fellow Peter Feiler. These publications highlight the latest work of SEI technologists in these areas. This post includes a listing of each publication, author(s), and links where they can be accessed on the SEI website.

Electronic Countermeasures

During the wars in Iraq and Afghanistan, insurgents' use of improvised explosive devices (IEDs) proliferated. The United States ramped up its development of counter-IED equipment to improve standoff detection of explosives and explosive precursor components and to defeat IEDs themselves as part of a broader defense capability. One effective strategy was jamming or interrupting radio frequency (RF) communications to counter radio-controlled IEDs (RCIEDs). This approach disrupts critical parts of RF communications, making the RCIED's communication to activate ineffective, saving both warfighter and civilian lives and property. For some time now, the cyber world has also been under attack by a diffused set of enemies who improvise their own tools in many different varieties and hide them where they can do much damage. This analogy has its limitations; however, here I want to explore the idea of disrupting communications from malicious code such as ransomware that is used to lock up your digital assets, or data-exfiltration software that is used to steal your digital data.

This blog post is coauthored by Jose Morales and Angela Horneman.

On May 12, 2017, in the course of a day, the WannaCry ransomware attack infected nearly a quarter million computers. WannaCry is the latest in a growing number of ransomware attacks where, instead of stealing data, cyber criminals hold data hostage and demand a ransom payment. WannaCry was perhaps the largest ransomware attack to date, taking over a wide swath of global computers from FedEx in the United States to the systems that power Britain's healthcare system to systems across Asia, according to the New York Times. In this post, we spell out several best practices for prevention and response to a ransomware attack.

When it comes to network traffic, it's important to establish a filtering process that identifies and blocks potential cyberattacks, such as worms spreading ransomware and intruders exploiting vulnerabilities, while permitting the flow of legitimate traffic. In this post, the latest in a series on best practices for network security, I explore best practices for network border protection at the Internet router and firewall.

The network time protocol (NTP) synchronizes the time of a computer client or server to another server or within a few milliseconds of Coordinated Universal Time (UTC). NTP servers, long considered a foundational service of the Internet, have more recently been used to amplify large-scale Distributed Denial of Service (DDoS) attacks. While 2016 did not see a noticeable uptick in the frequency of DDoS attacks, the last 12 months have witnessed some of the largest DDoS attacks, according to Akamai's State of the Internet/Security report. One issue that attackers have exploited is abusable NTP servers. In 2014, there were over seven million abusable NTP servers. As a result of software upgrades, repaired configuration files, or the simple fact that ISPs and IXPs have decided to block NTP traffic, the number of abusable servers dropped by almost 99 percent in a matter months, according to a January 2015 article in ACM Queue. But there is still work to be done. It only takes 5,000 abusable NTP servers to generate a DDoS attack in the range of 50-400 Gbps. In this blog post, I explore the challenges of NTP and prescribe some best practices for securing accurate time with this protocol.

In the 2016 Cyber Security Intelligence Index, IBM found that 60 percent of all cyber attacks were carried out by insiders. One reason that insider threat remains so problematic is that organizations typically respond to these threats with negative technical incentives, such as practices that monitor employee behavior, detect and punish misbehavior, and otherwise try to force employees to act in the best interest of the organization. In contrast, this blog post highlights results from our recent research that suggests organizations need to take a more holistic approach to mitigating insider threat: one that incorporates human involvement. In particular, positive incentives can produce better balance and security for organizations by complementing traditional practices to insider threat programs. This post also presents three practices to increase positive incentives that organizations can use to reduce insider threat.

As cyber-physical systems continue to proliferate, the ability of cyber operators to support armed engagements (kinetic missions) will be critical for the Department of Defense (DoD) to maintain a technological advantage over adversaries. However, current training for cyber operators focuses entirely on the cyber aspect of operations and ignores the realities and constraints of supporting a larger mission. Similarly, kinetic operators largely think of cyber capabilities as a strategic, rather than a tactical resource, and are untrained in how to leverage the capabilities cyber operators can provide. In this blog post, I present Cyber Kinetic Effects Integration, also known as CKEI, which is a program developed at the SEI's CERT Division that allows the training of combined arms and cyber engagements in a virtual battlefield.

Distributed denial-of-service (DDoS) attacks have been dominating the IT security headlines. A flurry of reporting followed the September 2016 attack on the computer security reporter Brian Krebs's web site KrebsonSecurity when he reported attack traffic that was at the unprecedented scale of gigabytes per second. In November, my colleague Rachel Kartch wrote "DDOS Attacks: Four Best Practices for Prevention and Response," outlining what we can do to defend against these attacks. In this blog post, I tell the story of the Mirai powered botnet that's been harnessed in some of these recent attacks and which has also received its own share of press. My purpose is to explore the vulnerabilities that Mirai exploits and describe some simple practices that could help transform our Internet devices to mitigate the risk posed by botnets.

The Domain Name System (DNS) is an essential component of the Internet, a virtual phone book of names and numbers, but we rarely think about it until something goes wrong. As evidenced by the recent distributed denial of service (DDoS) attack against Internet performance management company Dyn, which temporarily wiped out access to websites including Amazon, Paypal, Reddit, and the New York Times for millions of users down the Eastern Seaboard and Europe, DNS serves as the foundation for the security and operation of internal and external network applications. DNS also serves as the backbone for other services critical to organizations including email, external web access, file sharing and voice over IP (VoIP). There are steps, however, that network administrators can take to ensure the security and resilience of their DNS infrastructure and avoid security pitfalls. In this blog post, I outline six best practices to design a secure, reliable infrastructure and present an example of a resilient organizational DNS.

Late last month, Internet users across the eastern seaboard of the United States had trouble accessing popular websites, such as Reddit, Netflix, and the New York Times. As reported in Wired Magazine, the disruption was the result of multiple distributed denial of service (DDoS) attacks against a single organization: Dyn, a New Hampshire-based Internet infrastructure company.

DDoS attacks can be extremely disruptive, and they are on the rise. The Verisign Distributed Denial of Service Trends Report states that DDoS attack activity increased 85 percent in each of the last two years with 32 percent of those attacks in the fourth quarter of 2015 targeting IT services, cloud computing, and software-as-a-service companies. In this blog post, I provide an overview of DDoS attacks and best practices for mitigating and responding to them based on cumulative experience in this field.

This post was co-authored by Nancy Mead.

Cyber threat modeling, the creation of an abstraction of a system to identify possible threats, is a required activity for DoD acquisition. Identifying potential threats to a system, cyber or otherwise, is increasingly important in today's environment. The number of information security incidents reported by federal agencies to the U.S. Computer Emergency Readiness Team (US-CERT) has increased by 1,121 percent from 5,503 in fiscal year 2006 to 67,168 in fiscal year 2014, according to a 2015 Government Accountability Office report. Yet, our experience has been that it is often conducted informally with few standards. Consequently, important threat scenarios are often overlooked.

Given the dynamic cyber threat environment in which DoD systems operate, we have embarked on research work aimed at making cyber threat modeling more rigorous, routine, and automated. This blog post evaluates three popular methods of cyber threat modeling and discusses how this evaluation will help develop a model that fuses the best qualities of each.

Network flow plays a vital role in the future of network security and analysis. With more devices connecting to the Internet, networks are larger and faster than ever before. Therefore, capturing and analyzing packet capture data (pcap) on a large network is often prohibitively expensive. Cisco developed NetFlow 20 years ago to reduce the amount of information collected from a communication by aggregating packets with the same IP addresses, transport ports, and protocol (also known as the 5-tuple) into a compact record. This blog post explains why NetFlow is still important in an age in which the common wisdom is that more data is always better. Moreover, NetFlow will become even more important in the next few years as communications become more opaque with the development of new protocols that encrypt payloads by default.