The mobility landscape has evolved significantly in the past five years. Businesses are increasingly looking outside of their home markets to broaden their talent pools and place key skills where they are needed most. This also means that as companies expand to beyond their home markets, talent mobility can be the key competitive differentiator for success. The World Economic Forum recently shared in their Human Capital Report for 2015 that "Talent not capital will be the key factor linking innovation, competitiveness and growth in the 21st century." This will only become more important in the future, as companies are...

By Julien Delange Member of the Technical Staff Mismatched assumptions about hardware, software, and their interactions often result in system problems detected too late in the development lifecycle, which is an expensive and potentially dangerous situation for developers and users of mission- and safety-critical technologies. To address this problem, the Society of Automotive Engineers (SAE) released the aerospace standard AS5506, named the Architecture Analysis & Design Language (AADL). The AADL standard,defines a modeling notation based on a textual and graphic representation used by development organizations to conduct lightweight, rigorous—yet comparatively inexpensive—analyses of critical real-time factors, such as performance, dependability, security, and data integrity. AADL models capture both software and hardware components, as well as their interactions, including the association of a software process on a processor or the deployment of connection on a bus. The AADL standards committee, led by my colleague, Peter Feiler, who played an instrumental role in the development of AADL, meets regularly with members from around the globe who represent a wide variety of industries, from avionics to aerospace, to discuss evolving elements of the standard and to work together on action items from prior standards meetings. In this post, we present highlights from a series of podcasts that we recorded with Feiler and four members of the standards committee discussing their real-word application and experiences with AADL. The AADL standard includes abstractions of software, computational hardware, and system components for specifying real-time, embedded, and high-dependability systems with their software/hardware concerns and their specific requirements (such as scheduling and bus latency or jitter)  validating the system and ensuring that stakeholders’ requirements can be achieved Organizations have been using the AADL standard for nearly a decade. An early adopter was the European Space Agency, which leads the ASSERT project, which eventually became The ASSERT Set of Tools for Engineering (TASTE) targeted at the design and implementation of safety-critical systems. This project relied on AADL from its inception, and project members continue to use AADL to model, validate, and produce software. From this early use of AADL, many other projects and communities have adopted the language. The AADL committee and its members tracked users’ experiences and, in response, published a new version of the AADL standard in 2009. The committee also released a minor revision in September 2012. The remainder of this post includes conversations that Feiler had with four committee members representing various industries who have adopted AADL, including aviation and aerospace. AADL and Aerospacefeaturing Myron Hecht and Peter Feiler Myron Hecht’s research at Aerospace focuses on safety, reliability, and model-based system engineering and its application to quantitative and qualitative reliability analysis methods. He has previously worked in the domains of nuclear reactors, air traffic control, and avionics. During the podcast interview, Hecht stated that AADL represents a path for enabling practitioners in the dependability community: By dependability, I mean reliability, safety, and security, to be able to interchange models and thoughts and analyses in a structured way. The problem with the field at this point is that there are a lot of good ideas, but we don’t understand each other because it takes too long to figure out what everybody is doing. The biggest problem that we have in these analyses is the unstated assumptions and unstated limitations. The sooner we get onto a standard platform where we’re all speaking the same discipline really, the sooner we can begin to make major progress in building the next generation of computerized systems, in which people’s lives may depend even more on the computer itself, without any manual intervention. I have no idea how we’re going to do driverless cars. I have no idea how we’re going to do home medical devices for critical illnesses unless we really get greater confidence in our ability to do the analyses. When asked how AADL contributed to helping Aerospace make the transition from unstated to stated assumptions and limitations, Hecht responded as follows: Well, the most important contribution that AADL made from its origination in the aircraft industry, when it was born out of an earlier project from DARPA, where they really intended to develop real-time systems for avionics applications, simply by specifying them in the design. When you work in that environment, one of the things that you’re really worried about is what happens if things go wrong. If your car radiator blows over, you can stop by the side of the road. Hecht used the first version of AADL’s error model annex, which was released in 2006, and extended some of the original tooling work by Ana Rugina to build a tool suite that helps him in his work. Hecht leveraged the AADL notations extended with reliability information to generate safety models and generates safety analysis documents from the architecture, such as failure mode and effect analysis (FMEA) reports. Well, I think what is more to the point is that they get insight into the failure behavior and the weaknesses of their system and what they might have to do to improve it. Not only that, but the sponsor of their work, who is typically not the designer himself or themselves, is going to know what’s going on. Going to be able to monitor that part of the process and program manager...So, that constant feedback between a design and analysis, which now becomes a very tightly coupled loop in a very, very rapid process, is one of the key enablers to enable us to build complex safety-critical, life-critical, and mission-critical systems. To listen to the complete podcast, AADL and Aerospace, please visithttp://www.sei.cmu.edu/podcasts/podcast_episode.cfm?episodeid=88335&wtPodcast=AADLandAerospace. AADL and Edgewaterfeaturing Serban Gheorghe and Peter Feiler  Serban Gheorghe, vice-president of technology at Edgewater Computing Systems Inc., explained that he first became involved in AADL as Edgewater prepared to deploy a communication product. I got more involved in the technology. What we did is an AADL microkernel, basically with the intent on transforming it into a product. We are still working on that product. We have a few pilot trials in different places. The idea is to take AADL designs and convert them to our kernel and do all the static analysis in the same way and to have a very defined way of producing code, which is certified. So, the certification chain would be much easier to accomplish because it is always a constant concern. AADL provided a means for reducing evidence from a chain of certified components from the model into the kernel into the actual code. The whole value proposition of our product was that—independent of the models on the project where our tools are used and independent of the targets and how the targets are used—the same chain of tools tends to be used. Gheorghe added that Edgewater is working with several international organizations to build a constraints annex, which adds a standard set of analysis tools within the OSATE tool environment, which is open source. But, you know, there will always be more analysis, which is project specific, and constraints, which are project specific, which have to be enforced. What we are providing here is kind of a generic sub-language to be able to express those concerns and constraints. The ability to express those concerns and constraints serves as a catalyst for facilitating the evolution of a component. So, you can now create AADL components and fully characterize them in what you expect to get from them in terms of assumptions and guarantees. Secondly, I think it facilitates this concept of integrating multiple tools with multiple formalisms from the same repository. There are no different assumptions made by different tools. Feiler noted that this ability also enables architects to write specialized constraints for a project without implementing a new tool to enforce those constraints. Work on the constraints annex tries to leverage existing notations. For example, there is a standardized notation called Property Specification Language (PSL) that is used as one basis and then used to look at what elements need to be added to be useful in this context. To listen to the complete podcast, AADL and Edgewater, please visithttp://www.sei.cmu.edu/podcasts/podcast_episode.cfm?episodeid=88335&wtPodcast=AADLandAerospace. AADL and Télécom Paris Tech featuring Etienne Borde and Peter Feiler Etienne Borde, an assistant professor and researcher at Télécom ParisTech, explained that the technical university became interested in AADL because the embedded systems industry is growing at a robust pace, especially in Europe. Borde’s research focuses on software engineering for real-time, embedded systems. We use it as a teaching tool and as a research tool, and both parts are a little bit challenging. The research, of course, is because we have to face new problems. The teaching is because AADL is typically the kind of language that you can use for very advanced software engineering methods. We tried to teach it to students that physically did very little software in the labs. So, there is this kind of gap between what they’re able to understand about software engineering challenges and what AADL is meant to answer. AADL has helped systems engineers understand how software affects their decisions or how their decisions affect software performance. This is typically why we are interested in AADL as well. It’s because it’s a very good language for us, in our opinion, to tackle the issues that you have in safety-critical, embedded systems. So, those [systems] for which you need to have very strong guarantees in the behavior of your software applications. Borde added that his team is mainly using AADL in its research to make the prediction of the software applications or the configuration of the operating systems that will host the software applications. The operating systems in safety-critical, embedded systems have very different characteristics than in standard computer systems. Of course, you can’t accept that your operating system fails the same way that your home operating system could fail…You can’t have delays of tasks. You need to have specific operating systems. Those are quite difficult to configure. You have to be careful in the configuration process of those and the type of guarantees that you can manage by this configuration process. Feiler added that Borde’s team at Télécom Paris Tech is working on code generation capabilities that automatically create the complete execution runtime from the model. This generated code integrates also the functional code written by potentially different suppliers. The individual pieces of application code may be written in either Simulink or another modeling language, Feiler added, but AADL provides the glue that interconnects them. To listen to the complete podcast, AADL and Telecom Paris Tech, please visithttp://www.sei.cmu.edu/podcasts/podcast_episode.cfm?episodeid=77231. AADL and Dassault Aviation Featuring Thierry Cornilleau and Peter Feiler At Dassault Aviation, Thierry Cornilleau contributes to a number of real-time and avionics software studies and projects focused on avionics and aerospace mechanics and aviation. As an engineer working in the avionics domain, Cornilleau is also interested in another standard, ARINC 653, and the connection between AADL and ARINC 653. Feiler noted that Cornilleau’s experience helps the AADL committee define the standard in ways that ensure it meets the needs of the avionics industry. Cornilleau provided inputs and insights to the committee when working on the AADL ARINC653 annex, a document that details how to represent ARINC653 architectures with AADL. Thanks to his contributions, the document has been considered mature enough to be published as an official SAE standard. Dassault is very progressive in its use of formal methods, including AltaRica, a language used for system fault modeling and analysis, which ties in to the error model annex. Cornilleau remarked that two important recent developments with AADL have been with the error modeling annex and the maturity of OSATE, a tooling environment that helps users implement AADL within the Eclipse open-source environment. Cornilleau added that other members of his team at Dassault serve on the ARINC 653 committee. In addition to laying out a partitioned architecture, regular interaction with members of the ARINC 653 committee provided guidance for monitoring the health of the avionics systems, Feiler said and added the following:  With our now more formalized notation, one could get into a discussion with them about how we can provide more formalized guidance on how we can express this health monitoring architecture that they are suggesting to people. So, what we get into is that the AADL Committee cooperates with other committees to put AADL to use in other settings as well. To listen to the complete podcast, AADL and Dassault Aviation, please visithttp://www.sei.cmu.edu/podcasts/podcast_episode.cfm?episodeid=433479. Additional Resources For more information about the Architecture Analysis & Design Language (AADL) please visithttp://www.aadl.info/aadl/currentsite/. To view a recent webinar, Architecture Analysis with AADL, please visithttps://www.webcaster4.com/Webcast/Page/139/5357.

Nic Harrison Director of Enabling Digital Delivery My friend and colleague Andrew Besford and I have been talking about tunnelling forwards from today (me) and tunnelling backwards from our 2020 vision (Andrew). In his recent Sprint DWP presentations, Andrew even used a photo of the breakthrough moment of the Channel Tunnel, when British and French tunnellers met under the English Channel in 1990. My Enable team exists in part to make sure all the digital services we are developing today are headed in the right direction to meet up with Andrew’s team's work in defining the way we arrange the business to deliver the services DWP needs in 2020. Enable is focussed on ensuring that the services we deliver as a department are consistent with the strategic aims of DWP (and wider Government). This means making sure all in-flight or proposed changes are examined to make sure they are aligned with our longer term strategy. To do this we have service architects in all major change programmes and a team of business architects who review all changes as they move through existing departmental governance. I have created a new forum called the Service Design Forum (SDF) where all these people meet face-to-face as a community, to understand who is doing what and when. This promotes sharing and re-use whilst reducing duplication and avoiding programme conflicts, without the need for heavyweight documentation and governance; an example of our new nimble ways of working. The SDF is a community made up of service design professionals from all digital projects / programmes supported by subject matter experts from other areas of the business, including Business Transformation Group (BTG) Design and Deliver functions, Operations, Technology, Finance and Commercial. The SDF acts as an expert support group to projects in the discovery and alpha phases of agile delivery. We advise on all aspects of service design including the make up of teams, security design, technology architecture (through our Technology members). We help projects to pool ideas, learn about good design standards (from our library of design and security patterns) and to understand what has already been built elsewhere so that can be re-used rather than built from scratch again and again. We ensure that projects using the agile delivery method are either fully aligned to our strategic vision or are "failed fast" to free up scarce resources and reduce waste. Those projects that move through alpha into beta to become full blown digital programmes are then subject to regular "strategic fit" reviews from the SDF as they pass through the formal PMU governance gates. The SDF also acts as the "knowledge share repository" where we publish all the lessons learned in the SDF, the various design patterns and act as a store of re-usable artefacts, available to all new and in flight work. Business design tells us what DWP needs to look like in the future, and service design turns that vision into services that are actually delivered to users: citizens, other government departments and our colleagues. These designs have user needs at their heart, so one of the functions of the SDF is to ensure all our designs follow the GDS design standards. We are training in-house DWP people on the service design standards, so we can make sure all of our services meet this standard on an ongoing basis during development, and not just at the points when they are assessed externally by GDS. The SDF is still new, we are learning by doing, we have already started to set up subject matter sub-groups to solve specific problems in parallel to the SDF meeting schedule. This is an exciting time to be involved with the transformation of DWP, and the SDF is the heartbeat of our interaction with programmes. I am excited to lead this function, where we will influence daily design decisions and help to shape the future of DWP.

By Todd WaitsProject Lead Cyber Security Solutions Directorate This post is the latest installment in a series aimed at helping organizations adopt DevOps. In a computing system, a context switch occurs when an operating system stores the state of an application thread before stopping the thread and restoring the state of a different (previously stopped) thread so its execution can resume. The overhead incurred by a context switch managing the process of storing and restoring state negatively impacts operating system and application performance. This blog post describes how DevOps ameliorates the negative impacts that "context switching" between projects can have on a software engineering team’s performance. In the book Quality Software Management: Systems Thinking, Gerald Weinberg discusses how the concept of context switching applies to an engineering team. From a human workforce perspective, context switching is the process of stopping work in one project and picking it back up after performing a different task on a different project. Just like computing systems, human team members often incur overhead when context switching between multiple projects. Context switching most commonly occurs when team members are assigned to multiple projects. The rationale behind the practice of context switching is that it is logistically simpler to allocate team members across projects than trying to have dedicated resources on each project. It seems reasonable to assume that splitting a person’s effort between two projects yields 50 percent effort on each project. Moreover, if a team member is dedicated to a single project, that team member will be idle if that project is waiting for something to occur, such as completing paperwork, reviews, etc. Using our computing system metaphor, this switching between tasks is similar to the concept of multi-threading, where if one thread blocks the process for some reason, other threads can perform other work, rather than waiting for the first thread to unblock. If all work was assigned only to the first thread, progress is much slower. While multi-threading may be sound reasoning in computing systems, the problem is that human workers don’t always get a nice 50-50 effort distribution. Effort is thus lost to context switching, and productivity may drop precipitously as the worker’s effort is spread across more projects. Per Project Effort Distribution In the above graph based on data from Quality Software Management: Systems Thinking, a team member with one project is able to devote 100 percent of his or her time to that project. A team member with two projects does not yield a perfect 50-50 split. The team member actually yields about 40 percent effort per project because of the amount of time (roughly 20 percent) needed for context switching. In other words, switching between projects requires an operational overhead for the team member to figure out where he or she left off, what needs to be done, how that work fits in the project, etc. Once a team member is assigned five projects, his or her ability to contribute to any given project drops below 10 percent, with 80 percent effort being lost to switching between project contexts. Effort Lost to Context Switching The efforts lost to context switching are not just time, but quality also suffers. In particular, context switching can increase buggy code committed, unavailability of team members, and missed tasks, which require additional effort from team members to repair the problems. Joel Spolsky compares the task switching penalty for computers and computer programmers: The trick here is that when you manage programmers, specifically, task switches take a really, really, really long time. That's because programming is the kind of task where you have to keep a lot of things in your head at once. The more things you remember at once, the more productive you are at programming.  A programmer coding at full throttle is keeping zillions of things in their [sic] head at once: everything from names of variables, data structures, important APIs, the names of utility functions that they wrote and call a lot, even the name of the subdirectory where they store their source code. If you send that programmer to Crete for a three week vacation, they will forget it all. The human brain seems to move it out of short-term RAM and swaps it out onto a backup tape where it takes forever to retrieve. How DevOps Can Help DevOps practices can help guard against some of the pitfalls of context switching, as well as alert the team when context switching is impacting product quality and team productivity. By leveraging continuous integration, any build failure will alert the team members when their contributions are impeding application or feature development. Likewise, automating the assignment of code reviews can insure code committed meets proper style and security standards. Regular communication between team members is critical, especially when balancing work between projects. Without clear, structured avenues of communication, problems associated with context switching will quickly fall through the cracks. Daily stand up meetings and utilizing enterprise communication tools allow team members to quickly identify when context switching may be adversely impacting their ability to deliver business value. Issue trackers help highlight when certain individuals may unknowingly take on too much work across too many projects. Ultimately, limiting the number of projects an individual team member works on is ideal. In those instances when splitting effort is required, however, leveraging DevOps tools and philosophies will help mitigate potential disasters, shift resources as needed, and continue delivering the business value necessary to your success. Every two weeks, the SEI will publish a new blog post offering guidelines and practical advice for 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. Additional Resources Hasan Yasar and Aaron Cois will host a webinar, What DevOps is Not, at 1:30 p.m ET on March 11, 2015. To register for the webinar, please click here. To listen to the podcast, DevOps—Transform Development and Operations for Fast, Secure Deployments, featuring Gene Kim and Julia Allen, please visit http://url.sei.cmu.edu/js. To read all of the blog posts in our series thus far, please visit http://blog.sei.cmu.edu/archives.cfm/category/devops-tips.

Just because "everyone" used to do something doesn’t mean it was the right or smart thing to do. That’s one of the good things about humanity - we often (although certainly not always) improve many aspects of our lives as the earth keeps spinning. Consumption of unhealthy diversions such as sugar-loaded cereal, soda and cigarettes is way down. Value Hard to Find If we can get smarter about what we devour, we should be able to do the same with the disdained annual performance review. Thankfully, we are. Perhaps nothing in the HR field is under as much attack these...

By Mike KonradPrincipal ResearcherSoftware Solutions Divisions As recent news headlines about Shellshock, Sony, Anthem, and Target have demonstrated, software vulnerabilities are on the rise. The U.S. General Accounting Office in 2013 reported that "operational vulnerabilities have increased 780 percent over the past six years." These vulnerabilities can be hard and expensive to eradicate, especially if introduced during the design phase. One issue is that design defects exist at a deeper architectural level and thus can be hard to find and address. Although coding-related vulnerabilities are preventable and detectable, until recently scant attention has been paid to vulnerabilities arising from requirements and design defects. In 2014, the IEEE Computer Society Center for Secure Design was established to "shift some of the focus in security from finding bugs to identifying common design flaws—all in the hope that software architects can learn from others’ mistakes." "We believe that if organizations design secure systems, which avoid such flaws, they can significantly reduce the number and impact of security breaches," the center states in its report Avoiding the Top 10 Security Design Flaws. On a separate front, a group of researchers from various disciplines within the Carnegie Mellon University Software Engineering Institute recently came together to explore the implications of design-related vulnerabilities and quantify their effects on system cost and quality. This post highlights key issues and findings of our work. Foundations of Our Work According to a report issued by the National Institute of Standards and Technology (NIST), "the cost benefits of finding and addressing defects early are staggering. For every $1 spent on addressing defects during the coding phase of development, it will cost an organization $30 dollars to address if detected in production." The economic consequences of vulnerabilities generally fall into two general types: Harm caused. Breaches are costly and cause loss of security, mission failures, theft of resources (including intellectual property and personal information), and hard-to-recover consumer confidence and trust. Fixing the problem. The time and cost expended to address known vulnerabilities and recover from breaches continues to increase at a pace that is faster than our ability to recruit and develop individuals having the necessary cybersecurity expertise. Growth trends indicate that unless steps are taken to address this issue, there will be a dearth of staff with the skills needed to identify vulnerabilities and deploy needed patches in the future. The SEI team worked to identify root causes in the requirements and design phases of the software development lifecycle. The team included researchers from two separate divisions within the SEI: one that is software engineering and acquisition practice focused (within the Software Solutions Division); the other focused on cyber threats and vulnerability analyses in the operational environment (within the CERT Division). These two disciplines are frequently disconnected from each other during development, which is one of the contributing factors that cause vulnerabilities to be overlooked early in the lifecycle. For example, while software developers typically focus on defects, the operations team homes in on vulnerabilities. The software development side of our team included William Nichols, an expert in the Team Software Process (TSP) and process measurement. Likewise, Julia L. Mullaney, of CERT, is also a TSP expert. We also worked with two vulnerability analysts from CERT: Michael Orlando and Art Manion. Andrew Moore, a researcher in the CERT Insider Threat Center and an expert on system dynamics, also contributed to our effort. The team wanted to highlight sound requirements-gathering and design practices regarding security. Such practices enable software developers to make more-informed decisions early in the software development lifecycle and thereby reduce the level of vulnerabilities released into production where they are much more costly to address. Our research pursued three objectives: gain a better understanding of the state of research on vulnerabilities originating in software requirements and design leverage the extensive data collected by the TSP team indicating where in the lifecycle defects were inserted and what methods and practices were being used develop an economic model demonstrating the impact of vulnerabilities introduced during the requirements and design phases Validating our Premise Early in our research, we reviewed key published literature on predicting security vulnerabilities in software. We focused on research into early indicators of vulnerabilities, such as what is known and when about potential vulnerabilities that might be actionable. We decided to conduct a systematic mapping study, which is a study of all the studies that exist on a topic. Mapping studies typically consist of the following four stages: identify the primary studies that may contain relevant research results conduct a second evaluation to identify the appropriate studies for further evaluation where appropriate, perform a quality assessment (examining for such issues as bias and validity) of the selected studies summarize results along a dimension of interest What we found is that, with few exceptions, there has been little coordinated or sustained effort to study design or requirements-oriented vulnerabilities. As detailed in the SEI technical report on this project, Data Driven Software Assurance: A Research Study, our team of researchers first wanted to validate our premise that there were vulnerabilities that occurred during requirements and design activities (more precisely, during requirements elicitation and analysis; and during architecture, design, and analysis). Our team also wanted to verify that these vulnerabilities were as serious as some of the more common coding-based vulnerabilities and that these had significant economic impact. In 2012, our team of researchers investigated vulnerabilities collected in the CERT vulnerability database, which, at the time, contained more than 40,000 cases. Specifically, we created a heuristic based on recurring keywords to eliminate coding-related vulnerabilities: VulNoteInitialDate is after 01/01/1970 and field Name does not contain overflow and field Name does not contain XSS and field Name does not contain SQL and field Name does not contain default and field Name does not contain cross and field Name does not contain injection and field Name does not contain buffer and field Name does not contain traversal From the resulting vulnerabilities, we next excluded reports of vulnerabilities that lacked sufficient information to determine a cause or had strong indications of implementation-related vulnerabilities. Of those that remained, the team completed an initial root cause analysis on each of the vulnerabilities to confirm that they are, in fact, likely to have been caused by requirements or design defects. From that list, we selected three vulnerabilities on which to conduct a detailed analysis. What follows is a brief analysis of the one of the requirements or design-related vulnerabilities that we identified from the CERT database, Vulnerability Note VU#649219 SYSRET 64-bit operating system privilege escalation vulnerability on Intel CPU hardware. What follows is the original CERT description of the vulnerability and its impact: Description. Some 64-bit operating systems and virtualization software running on INTEL CPU hardware are vulnerable to a local privilege escalation attack. The vulnerability may be exploited for local privilege escalation or a guest-to-host virtual machine escape. A ring3 attacker may be able to specifically craft a stack frame to be executed by ring0 (kernel) after a general protection exception (#GP). The fault will be handled before the stack switch, which means the exception handler will be run at ring0 with an attacker’s chosen RSP, causing a privilege escalation. Impact. This security vulnerability affects 64-bit operating systems or virtual machine hypervisors running on Intel x86-64 CPUs. The vulnerability means that an attacker might be able to execute code at the same privilege level as the operating system or hypervisor. When running a standard operating system, such as Linux or Windows, or a virtual machine hypervisor, such as Xen, a mechanism is needed to rapidly switch back and forth from an application, which runs with limited privileges, to the operating system or hypervisor, which typically has no restrictions. The most commonly used mechanism on the x86-64 platform uses a pair of instructions, SYSCALL and SYSRET. The SYSCALL instruction does the following: •    copies the instruction pointer register (RIP) to the RCX register •    changes the code segment selector to the operating system or hypervisor value A SYSRET instruction does the reverse; that is, it restores the execution context of the application. There is more saving and restoring to be done—of the stack pointer, for example—but that is the responsibility of the operating system or hypervisor. The difficulty arises in part because the x86-64 architecture does not use 64-bit addresses; rather, it uses 48-bit addresses, which gives a 256 terabyte virtual address space that is considerably more than is used today. The processor has 64-bit registers, but a value to be used as an address must be in a canonical form; attempting to use a value not in canonical form results in a general protection (#GP) fault. The implementation of SYSRET in AMD processors effectively changes the privilege level back to the application level before it loads the application RIP. Thus, if a #GP fault occurs because the restored RIP is not in canonical form, the CPU is in application state, so the operating system or hypervisor can handle the fault in the normal way. However, Intel’s implementation effectively restores the RIP first; if the value is not in canonical form, the #GP fault will occur while the CPU is still in the privileged state. A clever attacker could use this to run code with the same privilege level as the operating system. Intel stated that this is not a flaw in its CPU since it works according to its written spec. However, the whole point of the implementation was to be compatible with the architecture as defined originally by AMD. Quoting from Rafal Wojtczuk, "The [proximate] root cause of the vulnerability is: on some 64 bit OS, untrusted ring3 code can force the kernel to execute SYSRET instruction that would return to a non-canonical address. On Intel CPUs, this results in an exception raised while still in Ring0. This exception cannot be handled safely." (Edited to clarify that this is an attribution of a more immediate (or proximate) root cause.) Clearly, many operating system and hypervisor vendors with considerable market presence were affected. Multiple parties could have prevented the vulnerability because Intel’s SDM is very clear on the behavior of SYSRET (and not every x86-64-based operating system or hypervisor was affected). For example, they could have adopted a safer transition back to the application following a SYSCALL. While originally noted and reported by the Linux community back in 2006, the vulnerability was characterized and easily dismissed as a Linux-specific issue. Also from Wojtczuk, "This is likely the reason why developers of other operating systems have not noticed the issue, and they remained exploitable for six years." Intel could also have prevented the vulnerability by not introducing a dangerous re-interpretation of how to return from a rapid system call. Solution The references above coupled with the short time window for  designing, implementing, and releasing a resolution to the vulnerability (from April to June 2012) might give the impression that the software community easily found an alternative, safer way to handle SYSRET (e.g., return other than through SYSRET or check for a canonical address). Implementing a safer method, however, was not so straightforward. That perhaps the same patch/approach might not work for all affected operating systems can be seen in the different ways the vulnerability can be exploited for different operating systems. So, each vendor must conduct its own careful analysis of what computing assets are at risk or can be leveraged for an exploit and carefully redesign/code system calls/returns to ensure safe transition from application to system and back again. Also, the intent of SYSCALL/SYSRET is to reserve these calls for operating system-only tasks but for which execution performance is critical (e.g., by minimizing saving off registers, except for those actually needed by the system function being called). Thus, the operating system-specific patch(es) need to be designed and coded for execution speed as well as safe transition. One of the vendors, Xen, has been particularly revealing relative to the considerable difficulties it encountered in working with select stakeholders to diagnose, design, code, and test patches for VU#649219, including providing a detailed timeline that describes an enormous amount of coordination and analysis behind the scenes, giving rise, no doubt, to enormous frustration. A detailed analysis of the three vulnerabilities is included in the appendices of our report. Developing a Systems Dynamic Economic Model After conducting a detailed analysis of the vulnerabilities, we next leveraged information using our knowledge of Team Software Process (TSP). Created by Watts Humphrey, TSP guides engineering teams that are developing software-intensive products to establish a mature and disciplined engineering practice that produces secure, reliable software in less time and at lower costs.  Our aim in constructing an economic model was to allow people to study systems with many interrelated factors using stocks and flows (dynamic simulation). In creating a simulation model, we first wanted to represent the normal behavior of the system and then change a few assumptions to see how the model's responses change. Creating an economic model using the systems dynamics method, which is detailed in Business Dynamics: Systems Thinking and Modeling for a Complex World by John D. Sternam, enables analysts to model and analyze critical behavior as it evolves over time within socio-technical domains. A key tenet of this method is that the dynamic complexity of critical behavior can be captured by the underlying feedback structure of that behavior. Using Vensim, a dynamic simulation tool, we created a model that represents the design vulnerability lifecycle and includes variables representing key design and defect-related parameters gleaned from the literature search, the detailed vulnerability analysis, and experience with the TSP process. It is important to note that we did not calibrate the model with any one organization’s specific data. To make the most use of the economic model, one would need to calibrate it with an organization’s specific data. This model is not usable (transitionable) as is, except to make a hypothetical argument as to why design practice is important. Wrapping Up and Looking Ahead Our research confirmed that the current ship-then-fix approach to software quality is sub-optimal and in the long term untenable. Our analyses of vulnerabilities included examples in which vulnerabilities could never be fully eradicated from the user community once the product was distributed. Moreover, the system dynamics model that we developed showed that even at the level of a single development increment, the economics often favor earlier attention to security-related requirements and design, as well as ongoing validation. In other words, it is often not necessary to consider longer time scales to experience benefits that exceed the costs, for all major stakeholders. Looking ahead, we would be interested in piloting and calibrating our economic model with an organization that has quality data on its defects including where they originated. If you are an organization interested in piloting this economic model, please send an email to info@sei.cmu.edu. We welcome your feedback on our research in the comments section below.   Additional Resources To read the SEI technical report, Data-Driven Software Assurance: A Research Study, please visit http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=90086. To read the recently-released Avoiding the Top 10 Software Security Design Flaws, published by the IEEE Computer Society Center for Secure Design, please visit  http://cybersecurity.ieee.org/images/files/images/pdf/CybersecurityInitiative-online.pdf. To read the paper, Matching Attack Patterns to Security Vulnerabilities in Software-Intensive System Designs, by Dr. Laurie Williams and Michael Gegick, please visithttp://collaboration.csc.ncsu.edu/laurie/Papers/ICSE_Final_MCG_LW.pdf.

By Lori FlynnMember of the Technical StaffCERT Secure Coding Team This blog post was co-authored by Will Klieber. Each software application installed on a mobile smartphone, whether a new app or an update, can introduce new, unintentional vulnerabilities or malicious code. These problems can lead to security challenges for organizations whose staff uses mobile phones for work. In April 2014, we published a blog post highlighting DidFail (Droid Intent Data Flow Analysis for Information Leakage), which is a static analysis tool for Android app sets that addresses data privacy and security issues faced by both individual smartphone users and organizations. This post highlights enhancements made to DidFail in late 2014 and an enterprise-level approach for using the tool. Analyzing Dataflows in Android Application Sets The SEI’s CERT Secure Coding Team has assisted numerous government and nongovernment organizations vet software developed for the Android operating system (OS), which has dominated the mobile device market, but continues to struggle with security problems. The Android OS has become the platform of choice for the Department of Defense (DoD), which recently purchased 7,000 Samsung Galaxy Note II mobile smartphones for the Army’s Nett Warrior System, which aims to arm soldiers with the technology they need to make faster, more accurate decisions during combat. In early 2014, we designed and implemented a novel taint flow analyzer (DidFail) that combines and augments the existing Android dataflow analyses of FlowDroid (which identifies intra-component taint flows) and Epicc (which identifies properties of intents such as the action string) to track both inter-component and intra-component dataflow in a set of Android applications. DidFail enables an organization (e.g., enterprise, app store, or security system provider) to pre-analyze apps, so that the analysis for potential dataflow problems (within the set of apps on the phone) is fast when a user requests to install a new app. Phase 1 of DidFail can be performed on one application at a time and, once completed, does not need to be run again. Phase 2 of DidFail (app set analysis) typically takes only seconds. DidFail addresses a problem often seen in dataflow analysis: the leakage of sensitive information from a sensitive source to a restricted sink. Both "source" and "sink" are commonly used terms in flow analysis. We define source as an external resource (external to the app, not necessarily external to the phone) from which data is read. We define sink as an external resource to which data is written. By analyzing information flow, we can find issues that could affect data integrity and/or privacy. A privacy violation occurs when information flows from a sensitive source to a sink that is not authorized to receive the data. An integrity violation occurs when untrusted data is sent to a sink that is supposed to store only trusted data. The DidFail analysis of a given set of apps takes place in two phases: In the first phase, we determine the dataflows enabled individually by each app and the conditions under which these flows are possible. In the second phase, we build on the results of the first phase to enumerate the potentially dangerous dataflows enabled by the whole set of applications. DidFail differs from pure FlowDroid, which also analyzes flows of tainted information. FlowDroid taintflow analysis is limited to a single component of a single app; DidFail analyzes potentially tainted flows between apps and, within a single app, between multiple components. Recent Enhancements to DidFail In 2014, we worked to improve DidFail in collaboration with graduate students from Carnegie Mellon University’s Information Networking Institute (INI) and Department of Electrical and Computer Engineering (ECE). The graduate students are Will Snavely (INI), Jonathan Burket (ECE), Jonathan Lim (INI), and Wei Shen (INI). Together, we made improvements to DidFail to help it succeed with more applications and detect more flows. First, we developed a new framework for testing the DidFail analyzer, which includes a setup for cloud-based testing and instrumentation to measure the performance of the analyzer. The new setup for cloud-based testing enables us to take advantage of commercially-available powerful virtual machines and to use multiple virtual machines in parallel for faster test completion. Additionally We modified DidFail to use the most current version of FlowDroid and Soot (which includes a better module for converting between Android .dex representation and Soot’s Jimple intermediate representation), increasing its success rate from 18 percent to 68 percent on our test suite of real-world apps. We made enhancements to enable analysis of some dataflows through static fields, BroadcastReceiver components, and Service components. We developed new apps to test the analytical features added to DidFail. Using the improved DidFail analyzer and the cloud-based testing framework, we tested the system on the new test apps and apps from the Google Play store. The SEI technical report Making DidFail Succeed: Enhancing the CERT Static Taint Analyzer for Android App Sets details the new testing framework, enhancements to DidFail, newly developed test apps, and test results. Also, the latest enhancements are available for free download, with instructions for building DidFail from the source code. DidFail Practicality at an Enterprise Level Our initial prototype yielded too many false positives. In particular, DidFail gave too many warnings about potential flows that turned out not be realizable. We are currently improving the precision of DidFail, while also developing a realistic and feasible plan for deploying it at the enterprise level. Deploying DidFail at an Enterprise Level Enterprises could use DidFail to protect their (and their personnel’s) data on Android smartphones. DidFail identifies dataflows from sources to sinks for a set of apps. When implemented in an enterprise, there will be multiple apps, numerous flows, and users unfamiliar with the concept of a dangerous flow. As recommended in the NIST report, Vetting the Security of Mobile Applications, organizations need to create policies concerning permitted and forbidden dataflows. An enterprise could use DidFail in conjunction with a commercial security system to help set and enforce dataflow policies. The enterprise’s subdivisions (e.g., IT, security, and administration) and Android end-users could also provide input useful for protecting the organization’s particular types of sensitive data in its particular use scenarios. Policies could be expressed as white lists or black lists: White list example: A policy might specify that data from the microphone cannot flow to any sink except the public switched telephone network (PSTN). Black list example: A policy might be set to alert the user if an app set could allow data to flow from on-device storage to the internet. As future work, DidFail can be extended to report what user interaction, if any, is required for a flow to occur. For example, consider an app that records audio from the microphone and sends this audio data over the internet. This flow might be considered unacceptable if the app launches when the phone starts up and doesn’t require any user interaction. On the other hand, the flow might be considered acceptable if the app requires the user to press a "record" button before reading from the microphone. When flows are identified that don’t comply with one or more policies, there are a variety of mitigations or steps that can be taken: For personal use, the system can alert the user to the existence of the flow and confirm whether the user still wants to install the app. For use in an enterprise, the system might refuse installation of the app. Alternatively, if the non-compliant flow relies on the existence of multiple installed apps, the system could give the option to remove previously-installed apps to prevent the non-compliant flow. Another option would involve dynamically blocking non-compliant flows, which can be accomplished through a variety of approaches: -The app could be blocked from reading particular sources. -The app could be blocked from writing to particular sinks. -When an app sends an implicit intent, (i.e., an intent that does not expressly designate  its recipient), the system could block that intent from being sent to certain other apps. These dynamic changes would require modifications to the Android OS. Some systems that work within or replace the Android OS, such as CyanogenMod and TaintDroid, can perform those operations. Our DidFail taint flow analysis tool could be incorporated in many application security-checking systems. We hope DidFail will eventually be used widely, including in: public app stores and their integrated security systems such as Google Play Store; corporate enterprise Android security systems; mobile computing security systems; and government app stores and processes, including NIST’s AppVet mobile app vetting system, DHS’s Carwash system for inspecting app security, DARPA Trans Apps secure app store, and the DoD’s planned enterprise Mobile Application Stores (MAS) and conjunct Mobile Device Management (MDM) systems. Enterprises wishing to use smartphones in a safe and effective manner need to institute policies governing their use. Studies such as Android Permissions: User Attention, Comprehension, and Behavior have shown that end users, if presented with a request for permissions, generally approve the permission. The research results discussed in Android Permissions Demystified indicate that often developers request unnecessary permissions and do not understand the true implications of permissions. The Android platform requires users to accept all requested permissions or the app does not install. In contrast, CyanogenMod, which is an open-source Android-based OS, allows the user to grant or deny individual permissions to the app. Similar policies could be used for an enterprise’s iPhone and Android devices at a more abstract level, to prevent dataflows from a specified source to a specified sink (e.g., an organization that prohibits data from the corporate email to be sent out as a text message). Our work focuses on the mechanism rather than the policy, but our analytical mechanism would enable the enterprise to enforce policies it needs or wants. Prior to DidFail, no tool existed that would allow organizations to statically trace tainted dataflows through multiple apps. Beyond using DidFail as a component in a system for setting, analyzing, and enforcing dataflow policiesfor Android smartphones, enterprises may use DidFail analyses for additional purposes. Security researchers can use DidFail to check for dataflows that can be exploited in ways end users would not expect. Developers can also use DidFail to check if the app being developed might accidentally enable dangerous dataflows. Figure 1 shows an example flow of information from the time a user "UserX" asks to install an app, through the enterprise-integrated DidFail app set taint flow analysis and enterprise policy check. In this example, the data flows found were policy-compliant and the app was allowed to be installed. Other Tool Improvements and Looking Ahead "New technologies may offer the promise of productivity gains and new capabilities, but if these new technologies present new risks, the organizations’ IT professionals, users, and business owners should be fully aware of these new risks and develop plans to mitigate them or be fully informed before accepting the consequences of them," Quirolgico et al. wrote in NIST Special Publication (SP) 800-163 Vetting the Security of Mobile Applications. In addition to developing approaches for implementing DidFail at the enterprise level, our team continues to work to improve the precision and soundness of the tool, so that it enables organizations and individuals to have greater awareness of risks associated with adopting Android smartphones and developing plans for mitigating these risks. We are interested in collaborating with organizations to pilot future prototypes. Organizations interested in collaborating with us are invited to contact us. Additional Resources Read the SEI technical report, Making DidFail Succeed: Enhancing the CERT Static Taint Analyzer for Android App Sets, for more detailed information about the work described in this post. To download the DidFail tool, please visit https://www.cert.org/secure-coding/tools/didfail.cfm Read the SEI technical report, Mobile SCALe: Rules and Analysis for Secure Java and Android Coding, for more information about the work described in this blog post. To view the Android wiki on the CERT Secure Coding site, please visit https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=111509535.

Sommer and Sandra are graduates of the first cross-government Digital Academy. It was held in February this year, shortly before the Digital Academy celebrated its first birthday. Sandra works in the Legal Aid Agency; and Sommer within the NHS Health and Social Care Information Centre. They talk about their experience of the cross-government Digital Academy here. Sandra Berry - Legal Aid Agency I was at CS Live in Newcastle in July 2014 and one of the presentations from DWP was ‘Digital Transformation in Government’. DWP had introduced a Digital Academy to build capability and push the digital transformation. This was like a light-bulb moment for me and my first thought was this is exactly what the Legal Aid Agency needs. I focussed on finding out more about how the Academy was set up, how it worked and how successful this had been. I joined the first cross-government Digital Academy and, although I was nervous and not sure what to expect as I had never worked with the agile methodology, I needn’t have worried. The opportunity surpassed my expectations of what could be achieved in a very short time. I am privileged to have had the opportunity to work with such a fantastic group and extraordinary leaders at the Academy. If government departments are really looking to transform peoples’ lives they need to have an Academy at their departments exactly the same as the one at the DWP. I had an amazing time and have never felt so empowered to look forward to the future and really transform peoples’ lives. Sommer Croft - Health and Social Care Information Centre I had a different background to many of the other Digital Academy cohorts; I’d worked as part of an agile team for 2 years delivering the new backend infrastructure for the NHS, and was a Scrum Master for 5 months. The cross-government Digital Academy was a fantastic experience for me; it consolidated so much of my learning and taught me new tools and techniques which I know I will be able to introduce within my organisation.   Several of my cohorts and I had a debate on whether DWP was the right government department to run the cross-government Digital Academy; and if it should be managed centrally by someone such as GDS. We all came to the conclusion that DWP were excellently placed to run this and establish a cross-government community as all cohorts felt at ease and could be open and honest around issues within their own departments; as well as having discussions on how to resolve these issues. If we’re truly going to transform digital services for citizens in the UK we need every government department to be taking this forward for their services and users.

Congrats - You’ve been promoted!  Oftentimes, when you accept a new role at your current company, you will find yourself caught between your old duties and your new duties.  As in any new role, there is likely a defined transition period - typically between 2-3 weeks.  But what happens when your old team comes to you on day 2 of your new role and asks you to take care of something for them?  It’s important to understand when and how to say no to your old team. After you’ve accepted your new...

By Tim PalkoSenior Member of the Technical Staff CERT Cyber Security Solutions Division This post is the latest installment in a series aimed at helping organizations adopt DevOps. The workflow of deploying code is almost as old as code itself. There are many use cases associated with the deployment process, including evaluating resource requirements, designing a production system, provisioning and configuring production servers, and pushing code to name a few. In this blog post I focus on a use case for configuring a remote server with the packages and software necessary to execute your code. This use case is supported by many different and competing technologies, such as Chef, Puppet, Fabric, Ansible, Salt, and Foreman, which are just a few of which you are likely to have heard on the path to automation in DevOps. All these technologies have free offerings, leave you with scripts to commit to your repository, and get the job done. This post explores Fabric and Ansible in more depth. To learn more about other infrastructure-as-code solutions, check out Joe Yankel's blog post on Docker or my post on Vagrant. One difference between Fabric and Ansible is that while Fabric will get you results in minutes, Ansible requires a bit more effort to understand. Ansible is generally much more powerful since it provides much deeper and more complex semantics for modeling multi-tier infrastructure, such as those with arrays of web and database hosts. From an operator’s perspective, Fabric has a more literal and basic API and uses Python for authoring, while Ansible consumes YAML and provides a richness in its behavior (which I discuss later in this post). We'll walk through examples of both in this posting. Both Fabric and Ansible employ secure shell (SSH) to do their job in most cases. While Fabric leverages execution of simple command-line statements to target machines over SSH, Ansible pushes modules to remote machines and then executes these modules remotely, similar to Chef. Both tools wrap these commands with semantics for basic tasks such as copying files, restarting servers, and installing packages. The biggest difference between them is in the features and complexity that is presented to the operator. Here is a Fabric script that installs Apache on a remote server: fabfile.py from fabric.api import run,env env.hosts = ['foo.bang.whiz.com'] def install_apache(): run('apt-get install apache2', with_sudo=True) This script is executed with: $ fab install_apache One obvious note here is that we are writing in Python, which provides to the operator all the features of the language. In this Fabric example, we are creating a task: install_apache, calling the run() operation, and literally spelling out the command we want to execute. Fabric handles reading the host name from the environment variable we set. In contrast, here is an Ansible script that does the same thing Fabric did above, using a "playbook" and a "role": hosts foo.bang.whiz.com roles/web/tasks/main.yml name: install Apache apt: name=apache2 state=present site.yml name: install Apache hosts: foo.bang.whiz.com roles: - web This script is executed with: $ ansible-playbook deploy.yml The playbook, and point of entry, is site.yml. This script declares plays, where each play states to what hosts each role should be applied. Each play starts with a name parameter and goes on to declare its targeted hosts and roles to use. The roles themselves are defined by a structure of subfolders containing more YAML that defines what modules to execute with what parameters for that role. In this example, we define a web role containing the apt module. There is a subtle distinction about roles: hosts do not have roles. Instead, hosts are decorated with roles according to the playbook. Also, a playbook can have multiple plays, multiple roles can be applied to a host, roles can have multiple task files, and tasks can have multiple modules. Moreover, we can define groups for hosts and even put those groups into higher level groups. Here is a more complete Ansible example: hosts [webservers] foo01.bang.whiz.com foo02.bang.whiz.com [dbservers] db.bang.whiz.com site.yml name: configure a webserver hosts: webservers roles: - web name: configure a database server hosts: dbservers roles: - db roles/web/tasks/main.yml name: install apache apt: name=apache2 state=present roles/db/tasks/main.yml name: install mysql apt: name=mysql-server state=present All the elements in this example are executed with: $ ansible-playbook site.yml First, notice that we have added more hosts and group them in the hosts file. Second, we've added a second play to the playbook. One nice feature that we don't see by looking at the playbook or the roles is that Ansible will gather information for all of the hosts at runtime and only apply changes necessary to obtain the desired state. In other words, if it ain't broke, don't fix it. Also, note that this is a stripped-down example of Ansible, and does not exemplify its many other features, such as defining and iterating over lists in a module call, using metadata from the hosts such as IP addresses and OS versions dynamically at runtime, and chaining roles together as dependencies. I highly recommend watching the Ansible quick start video here. Now, back to Fabric. Here is roughly the same result using Fabric's tooling: fabfile.py from fabric.api import env,hosts,run,execute env.roledefs['webservers'] = ['foo01.bang.whiz.com', 'foo02.bang.whiz.com'] env.roledefs['dbservers'] = ['db.bang.whiz.com'] @roles('webservers') def install_apache(): run('apt-get install apache2', with_sudo=True) @roles('dbservers') def install_mysql(): run('apt-get install mysql-server', with_sudo=True) def deploy(): execute(install_apache) execute(install_mysql) Note that we are contained to a single file, although the raw size of our configuration in bytes is roughly the same as in Ansible. On a more technical level, Fabric's semantics are much "thinner" than Ansible's. For example, when we target a host with a role in Ansible, we are effectively asking it to check the host for a multitude of data points and evaluate its state before running any commands. Fabric is more of a what-you-see-is-what-you-get implementation, as demonstrated by its API: "run", "put", "reboot", and "cd" are common operations. A consequence of this simplicity is a lack of the rich features that we see in Ansible, such as its ability to pull in host information dynamically and use that information during execution. Here is a simple example of using Ansible’s dynamic host information: roles/web/tasks/main.yml name: install apache apt: name=apache2 state=present name: deploy apache configuration template: src=apache.conf.j2 dest=/etc/apache2/sites-enabled/apache.conf roles/web/templates/apache.conf.j2 <VirtualHost {{ ansible_default_ipv4.address }}:80> ... </VirtualHost> Here we see a new module being used: "template". By convention, Ansible will look in the role’s "templates" folder for the file supplied to the "src" attribute and deploy it to the location supplied to the "dest" attribute. But the magic here is that prior to application of this role, Ansible gathers a list of what are actually called "facts" from the host and provides that data to us in the scope of our YAML. In this example, it means we can supply our Apache configuration file with the IP address of whatever host to which the role is applied. Getting this kind of behavior with Fabric is work left to the operator. One last topic is how these tools handle authentication. Ansible's answer to this is in the playbook: site.yml - hosts: webservers remote_user: alice sudo: yes # optional sudo_user: bob # optional With Fabric, we simply set the environment variable: fabfile.py from fabric.api import env env.user = 'alice' Both Fabric and Ansible can use your public key, as well to remove the need to enter passwords. This blog posting provided a light introduction to two fairly powerful solutions to the infrastructure-as-code problem. By this point, you may have already decided which direction you want to go, but it's more likely that you have more questions than you started with. There are many features of both Fabric and Ansible that are best left to their respective and official documentation, but hopefully this post helped to you get started. Every two weeks, the SEI will publish a new blog post offering guidelines and practical advice for 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. Additional Resources To listen to the podcast, DevOps—Transform Development and Operations for Fast, Secure Deployments, featuring Gene Kim and Julia Allen, please visit http://url.sei.cmu.edu/js. To read all of the blog posts in our series thus far, please visit http://blog.sei.cmu.edu/archives.cfm/category/devops-tips.