By Greg Shannon
two consecutive years, organizations reported that insider crimes caused comparable damage (34 percent) to external attacks (31
percent), according to a recent cybercrime report
co-sponsored by the CERT Division at the Carnegie Mellon University
Software Engineering Institute. Despite this near parity, media reports
of attacks often focus on external attacks and their aftermath, yet an
attack can be equally or even more devastating when carried out from
within an organization. Insider threats are influenced by a combination
of technical, behavioral, and organizational issues and must be
addressed by policies, procedures, and technologies. Researchers at the CERT Insider Threat Center define insider threat as actions by an individual who meets the following criteria:
current or former employee, contractor, or business partner who has or
has had authorized access to an organization’s network, system, or data
intentionally exceeded or intentionally used that access in a manner
that negatively affected the confidentiality, integrity, or availability
of the organization’s information or information systems.
Insider threats are influenced by a combination of technical,
behavioral, and organizational issues that organizations must address
through policies, procedures, and technologies. Insider threats are
influenced by a combination of technical, behavioral, and organizational
issues and must be addressed by policies, procedures, and technologies.
Researchers at the The CERT Insider Threat Center provides analysis and
solutions to organizations through partnerships with the U.S.
Department of Defense, the U.S. Department of Homeland Security, the
U.S. Secret Service, other federal agencies, the intelligence community,
private industry, academia, and the vendor community. This blog post,
the second in a series, introduces the CERT Insider Threat Center blog, which highlights the latest research and security solutions to help organizations protect against insider threat.
By Greg Shannon
In 2014, approximately
1 billion records of personably identifiable information were
compromised as a result of cybersecurity vulnerabilities. In the
face of this onslaught of compromises, it is important to examine
fundamental insecurities that CERT researchers have identified and that
readers of the CERT/CC blog
have found compelling. This post, the first in a series highlighting
CERT resources available to the public including blogs and vulnerability
notes, focuses on the CERT/CC blog. This blog post highlights security
vulnerability and network security resources to help organizations in government
and industry protect against breaches that compromise data.
By Chris Taschner
CERT Cyber Security Solutions Directive
This post is the latest installment in a series aimed at helping organizations adopt DevOps.
security” often evokes negative feelings among software developers
since this term is associated with additional programming effort and
uncertainty. To secure software, developers must follow a lot of
guidelines that, while intended to satisfy some regulation or other, can be very restricting and hard to understand. As a result a lot of fear, uncertainty, and doubt can surround software security. This blog posting describes how the Rugged Software
movement attempts to combat the toxic environment surrounding software
security by shifting the paradigm from following rules and guidelines to
creatively determining solutions for tough security problems.
By Mike Gagliardi,
Software Solutions Division
In Department of Defense (DoD) programs, cooperation among software and system components is critical. A system of systems (SoS) is used to accomplish a number of missions where cooperation among individual systems is critical to providing (new) capabilities that the systems could not provide. SoS capabilities are a major driver in the architecture of the SoS and selection of constituent systems for the SoS. There are additional critical drivers, however, that must be accounted for in the architecture that significantly impact the behavior of the SoS capabilities, as well as the development and sustainment of the SoS and its constituent systems’ architectures. These additional drivers are the quality attributes, such as performance, availability, scalability, security, usability, testability, safety, training, reusability, interoperability, and maintainability. This blog post, the first in a series, introduces the Mission Thread Workshop (MTW), and describes the role that it plays in assisting SoS programs to elicit and refine end-to-end SoS mission threads augmented with quality attribute considerations.
By Donald Firesmith
Software Solutions Division
One of the most important and widely discussed trends within the software testing community is shift left testing, which simply means beginning testing
as early as practical in the lifecycle. What is less widely known, both
inside and outside the testing community, is that testers can employ
four fundamentally-different approaches to shift testing to the left.
Unfortunately, different people commonly use the generic term shift left
to mean different approaches, which can lead to serious
misunderstandings. This blog post explains the importance of shift left
testing and defines each of these four approaches using variants of the
classic V model to illustrate them.