writes "In our last post, DevOps and Docker, I introduced Docker as a tool to develop and deploy software applications in a controlled, isolated, flexible, and highly portable infrastructure. In this post, I am going to show you how easy it is to get started with Docker. I will dive in and demonstrate how to use Docker containers in a common software development environment by launching a database container (MongoDB), a web service container (a Python Bottle app), and configuring them to communicate forming a functional multi-container application. If you haven’t learned the basics of Docker yet, you should go ahead and try out their official tutorial here before continuing."Link to Original Source
writes "In 2014, the SEI blog has experienced unprecedented growth, with visitors in record numbers learning more about our work in big data, secure coding for Android, malware analysis, Heartbleed, and V Models for Testing. In 2014 (through December 21), the SEI blog logged 129,000 visits, nearly double the entire 2013 yearly total of 66,757 visits. As we look back on the last 12 months, this blog posting highlights our 10 most popular blog posts (based on the number of visits). As we did with our mid-year review, we will include links to additional related resources that readers might find of interest. When possible, we grouped posts by research area to make it easier for readers to learn about related areas of work. This blog post first presents the top 10 posts and then provides a deeper dive into each area of research.
Using V Model for Testing
Two Secure Coding Tools for Analyzing Android Apps (secure coding)
Common Testing Problems: Pitfalls to Prevent and Navigate
Four Principles of Engineering Scalable, Big Data Systems (big data)
A New Approach to Prioritizing Malware Analysis
Secure Coding for the Android Platform (secure coding)
A Generalized Model for Automated DevOps (DevOps)
Writing Effective Yara Signatures to Identify Malware
An Introduction to DevOps (DevOps)
The Importance of Software Architecture in Big Data Systems (big data)"Link to Original Source
writes "A zero-day vulnerability refers to a software security vulnerability that has been exploited before any patch is published. In the past, vulnerabilities were widely exploited even when a patch was available, which means they were not zero-day. Today, zero-day vulnerabilities are common. Notorious examples include the recent Stuxnet and Operation Aurora exploits. Vulnerabilities may arise from a variety of sources, but most vulnerabilities are the result of simple coding errors. Consequently, developers need to understand common traps and pitfalls in the programming language, libraries, and platform to produce code that is free of vulnerabilities. To address this problem, CERT published The CERT Oracle Coding Standard for Java in 2011. This book is version 1 of this standard and was written primarily for Java SE 6, but also covers features introduced in Java SE 7. This coding standard provides secure coding rules that help programmers recognize and avoid vulnerabilities in their products. Each rule provides simple instructions regarding what a programmer must and must not do. Each rule description is accompanied by noncompliant code examples, as well as compliant solutions that can be used instead. In this blog post, I examine a Java zero-day vulnerability, CVE 2012-0507, which infected half a million Macintosh computers, and consider how this exploit could have been prevented through adherence to two secure coding rules."Link to Original Source
writes "Typically, when we envision DevOps implemented in an organization, we imagine a well-oiled machine that automates infrastructure provisioning, code testing, and application deployment. Ultimately, these practices are a result of applying DevOps methods and tools. DevOps works for all sizes, from a team of one to an enterprise organization.
DevOps can be seen as an extension of an Agile methodology. It requires all the knowledge and skills necessary to take a project from inception through sustainment to be contained within a dedicated project team. Organizational silos must be broken down. Only then can project risk be effectively mitigated.
While DevOps is not, strictly speaking, continuous integration, delivery, or deployment, DevOps practices do enable a team to achieve the level of coordination and understanding necessary to automate infrastructure, testing, and deployment. In particular, DevOps provides organizations a way to ensure
- collaboration between project team roles
- infrastructure as code
- automation of tasks, processes, and workflows
- monitoring of applications and infrastructure
Business value drives DevOps development. Without a DevOps mindset, organizations often find their operations, development, and testing teams working toward short-sighted incentives of creating their infrastructure, test suites, or product increment. Once an organization breaks down the silos and integrates these areas of expertise, it can focus on working together toward the common, fundamental goal of delivering business value.
Well-organized teams will find (or create) tools and techniques to enable DevOps practices in their organizations. Every organization is different and has different needs that must be met. The crux of DevOps, though, is not a killer tool or script, but a culture of collaboration and an ultimate commitment to deliver value.
Every Thursday, the SEI will publish a new blog post that offers guidelines and practical advice to organizations seeking to adopt DevOps in practice. We welcome your feedback on this series, as well as suggestions for future content. Please leave feedback in the comments section below."Link to Original Source
writes "Tension and disconnects between software and systems engineering functions are not new. Grady Campbell wrote in 2004 that “systems engineering and software engineering need to overcome a conceptual incompatibility (physical versus informational views of a system)” and that systems engineering decisions can create or contribute to software risk if they “prematurely over-constrain software engineering choices” or “inadequately communicate information, including unknowns and uncertainties, needed for effective software engineering.” This tension holds true for Department of Defense (DoD) programs as well, which historically decompose systems from the system level down to subsystem behavior and breakdown work for the program based on this decomposition. Hardware-focused views are typically deemed not appropriate for software, and some systems engineers (and most systems engineering standards) have not yet adopted an integrated view of the two disciplines. An integrated view is necessary, however, because in complex software-reliant systems, software components often interact with multiple hardware components at different levels of the system architecture. In this blog post, I describe recently published research conducted by me and other members of the SEI’s Client Technical Solutions Division highlighting interactions on DoD programs between Agile software-development teams and their systems engineering counterparts in the development of software-reliant systems."Link to Original Source
writes "Earlier this month, the U.S. Postal Service reported that hackers broke into their computer system and stole data records including social security numbers for 2.9 million customers and 750,000 employees and retirees, according to reports on the breach. In the JP Morgan Chase cyber breach earlier this year, it was reported that hackers stole the personal data of 76 million households as well as information from approximately 8 million small businesses. This breach and other recent thefts of data from Adobe (152 million records), EBay (145 million records), and The Home Depot (56 million records) highlight a fundamental shift in the economic and operational environment, with data at the heart of today’s information economy. In this new economy, it is vital for organizations to evolve the manner in which they manage and secure information. Ninety percent of the data that is processed, stored, disseminated, and consumed in the world today was created in the past two years. Organizations are increasingly creating, collecting, and analyzing data on everything (as exemplified in the growth of big data analytics). While this trend produces great benefits to businesses, it introduces new security, safety, and privacy challenges in protecting the data and controlling its appropriate use. In this blog post, I will discuss the challenges that organizations face in this new economy, define the concept of information resilience, and explore the body of knowledge associated with the CERT Resilience Management Model (CERT-RMM) as a means for helping organizations protect and sustain vital information."Link to Original Source
writes "Melvin Conway, an eminent computer scientist and programmer, create Conway’s Law, which states: Organizations that design systems are constrained to produce designs which are copies of the communication structures of these organizations. Thus, a company with frontend, backend, and database teams might lean heavily towards three-tier architectures. The structure of the application developed will be determined, in large part, by the communication structure of the organization developing it. In short, form is a product of communication.
Now, let’s look at the fundamental concept of Conway’s Law applied to the organization itself. The traditional-but-insufficient waterfall development process has defined a specific communication structure for our application: Developers hand off to the quality assurance (QA) team for testing, QA hands off to the operations (Ops) team for deployment. The communication defined by this non-Agile process reinforces our flawed organizational structures, uncovering another example of Conway’s Law: Organizational structure is a product of process.
As the figure shown above illustrates, siloed organizational structures align with sequential processes, e.g., waterfall methodologies. The DevOps method of breaking down these silos to encourage free communication and constant collaboration is actually reinforcing Agile thinking. Seen in this light, DevOps is a natural evolution of Agile thinking, bringing operations and sustainment activities and staff into the Agile fold.
Every Thursday, the SEI Blog will publish a new blog post that will offer guidelines and practical advice to organizations seeking to adopt DevOps in practice. We welcome your feedback on this series, as well as suggestions for future content. Please leave feedback in the comments section below."Link to Original Source
writes "Soldiers in battle or emergency workers responding to a disaster often find themselves in environments with limited computing resources, rapidly-changing mission requirements, high levels of stress, and limited connectivity, which are often referred to as “tactical edge environments.” These types of scenarios make it hard to use mobile software applications that would be of value to a soldier or emergency personnel, including speech and image recognition, natural language processing, and situational awareness, since these computation-intensive tasks take a heavy toll on a mobile device’s battery power and computing resources. As part of the Advanced Mobile Systems Initiative at the Carnegie Mellon University Software Engineering Institute (SEI), my research has focused on cyber foraging, which uses discoverable, forward-deployed servers to extend the capabilities of mobile devices by offloading expensive (battery draining) computations to more powerful resources that can be accessed in the cloud, or for staging data particular to a mission. This blog post is the latest installment in a series on how my research uses tactical cloudlets as a strategy for providing infrastructure to support computation offload and data staging at the tactical edge."Link to Original Source
writes "A DevOps approach must be specifically tailored to an organization, team, and project to reflect the business needs of the organization and the goals of the project.
Software developers focus on topics such as programming, architecture, and implementation of product features. The operations team, conversely, focuses on hosting, deployment, and system sustainment. All professionals naturally consider their area of expertise first and foremost when discussing a topic. For example, when discussing a new feature a developer may first think "How can I implement that in the existing code base?" whereas an operations engineer may initially consider "How could that affect the load on our servers?"
When an organization places operations engineers on a project team alongside developers, it ensures that both perspectives will equally influence the final product. This is a cultural declaration that in addition to dev-centric attributes (such as features, performance, and reusability), ops-centric quality attributes (such as deployability and maintainability) will be high-priority.
Likewise, if an organization wants security to be a first-class quality attribute, a team member with primary expertise in information security should be devoted to the project team.
Every Thursday, the SEI Blog will publish a new blog post that will offer guidelines and practical advice to organizations seeking to adopt DevOps.
We welcome your feedback on this series as well as suggestions for future content. Please leave feedback in the comments section below."Link to Original Source
writes "In an era of sequestration and austerity, the federal government is seeking software reuse strategies that will allow them to move away from stove-piped development toward open, reusable architectures. The government is also motivated to explore reusable architectures for purposes beyond fiscal constraints: to leverage existing technology, curtail wasted effort, and increase capabilities rather than reinventing them. An open architecture in a software system adopts open standards that support a modular, loosely coupled, and highly cohesive system structure that includes the publication of key interfaces within the system and full design disclosure. One area where the Department of Defense (DoD) is concentrating on the development of service-oriented architectures and common technical frameworks is in the intelligence community, specifically the Defense Intelligence Information Enterprise (DI2E). As this blog post details, a team of researchers at the SEI Emerging Technology Center (ETC) and the Secure Coding Initiative in the SEI’s CERT Division, are working to help the government navigate these challenges in building the DI2E framework, which promotes reuse in building defense intelligence systems."Link to Original Source
writes "When we verify a software program, we increase our confidence in its trustworthiness. We can be confident that the program will behave as it should and meet the requirements it was designed to fulfill. Verification is an ongoing process because software continuously undergoes change. While software is being created, developers upgrade and patch it, add new features, and fix known bugs. When software is being compiled, it evolves from program language statements to executable code. Even during runtime, software is transformed by just-in-time compilation. Following every such transformation, we need assurance that the change has not altered program behavior in some unintended way and that important correctness and security properties are preserved. The need to re-verify a program after every change presents a major challenge to practitioners—one that is central to our research. This blog post describes solutions that we are exploring to address that challenge and to raise the level of trust that verification provides.
As we strive to ease the burden of effort surrounding verification for practitioners, we attempt to answer this question:
How can we ensure that the amount of verification work is proportional to the size of the change, as opposed to the size of the system?"Link to Original Source
writes "With the rise of multi-core processors, concurrency has become increasingly common. The broader use of concurrency, however, has been accompanied by new challenges for programmers, who struggle to avoid race conditions and other concurrent memory access hazards when writing multi-threaded programs. The problem with concurrency is that many programmers have been trained to think sequentially, so when multiple threads execute concurrently, they struggle to visualize those threads executing in parallel. When two threads attempt to access the same unprotected region of memory concurrently (one reading, one writing) logical inconsistencies can arise in the program, which can yield security concerns that are hard to detect. The ongoing struggle with concurrent threads of execution has introduced a whole class of concurrency-related issues, from race conditions to deadlock. Developers need help writing concurrent code correctly. This post, the second in a series on concurrency analysis, introduces Clang Thread Safety Analysis, a tool that was developed as part of a collaboration between Google and and the Secure Coding Initiative in the SEI's CERT Division. Clang Thread Safety Analysis uses annotations to declare and enforce thread safety policies in C and C++ programs."Link to Original Source
writes "Given that up to 70 percent of system errors are introduced during the design phase, stakeholders need a modeling language that will ensure both requirements enforcement during the development process and the correct implementation of these requirements. Previous work demonstrates that using the Architecture Analysis & Design Language (AADL) early in the development process not only helps detect design errors before implementation, but also supports implementation efforts and produces high-quality code. Our latest blog posts and a recent webinar have shown how AADL can identify potential design errors and avoid propagating them through the development process. Verified specifications, however, are still implemented manually. This manual process is labor intensive and error prone, and it introduces errors that might break previously verified assumptions and requirements. For these reasons, code production should be automated to preserve system specifications throughout the development process. This blog post summarizes different perspectives on research related to code generation from architecture models."Link to Original Source
writes "While conducting the research that produced The CERT Oracle Coding Standard for Java, the Secure Coding Team in the SEI's CERT Division identified best coding practices that, if followed, would eliminate vulnerabilities and other defects in Java programs. Together with collaborators from other organizations, the team in 2013 published Java Coding Guidelines: 75 Recommendations for Reliable and Secure Programs. Now the CERT Division is making the content of the Java Coding Guidelines book available free online."Link to Original Source
writes "Insider threat is the threat to organization’s critical assets posed by trusted individuals — including employees, contractors, and business partners — authorized to use the organization’s information technology systems. Insider threat programs within an organization help to manage the risks due to these threats through specific prevention, detection, and response practices and technologies. The National Industrial Security Program Operating Manual (NISPOM), which provides baseline standards for the protection of classified information, is considering proposed changes that would require contractors that engage with federal agencies, which process or access classified information, to establish insider threat programs. The proposed changes to the NISPOM were preceded by Executive Order 13587, Structural Reforms to Improve the Security of Classified Networks and the Responsible Sharing and Safeguarding of Classified Information. Signed by President Obama in September 2011, Executive Order 13587 requires federal agencies that operate or access classified computer networks to implement insider threat detection and prevention programs.
Since the passage of Executive Order 13587, the following key resources have been developed:
-The National Insider Threat Task Force developed minimum standards for implementing insider threat programs. These standards include a set of questions to help organizations conduct insider threat self-assessments.
-The Intelligence and National Security Alliance conducted research to determine the capabilities of existing insider threat programs
-The Intelligence Community Analyst-Private Sector Partnership Program developed a roadmap for insider threat programs.
CERT’s insider threat program training and certificate programs are based on the above resources as well as CERT’s own Insider Threat Workshop, common sense guidelines for mitigating insider threats, and in-depth experience and insights from helping organizations establish computer security incident response teams. As described in this blog post, researchers from the Insider Threat Center at the Carnegie Mellon University Software Engineering Institute are also developing an approach based on organizational patterns to help agencies and contractors systematically improve the capability of insider threat programs to protect against and mitigate attacks."Link to Original Source