By Mike Konrad Principal ResearcherSEI Software Solutions Division As recent news attests, the rise of sociotechnical ecosystems (STE)—which, we define as a software system that engages a large and geographically-distributed community in a shared pursuit—allows us to work in a mind space and a data space that extends beyond anything that we could have imagined 20 or 30 years ago. STEs present opportunities for tackling problems that could not have even been approached previously because the needed experts and data are spread across multiple locations and distance. Since STEs can be complex and have many diverse stakeholders, a key challenge faced by those responsible for establishing and sustaining them is eliciting requirements to inform their development efforts. Yet stakeholders often have requirements that they are not aware of, so they do not specify them. Uncovering these unstated requirements can be hard and is not well-supported by traditional approaches to requirements elicitation. This blog post describes initial results of an effort by researchers at the Carnegie Mellon University Software Engineering Institute—in addition to myself, the team included Nancy Mead, Robert Stoddard, and Mary Beth Chrissis—aimed at developing an approach for determining the unstated needs of stakeholders typical of large, diverse programs and especially STEs. Foundations of Our Work Apple founder Steve Jobs famously said "But in the end, for something this complicated, it's really hard to design products by focus groups. A lot of times, people don't know what they want until you show it to them." What Steve was saying is that there are often critical product features that end users are not even aware they need, and that an insightful designer will figure out that need and offer it.  Therefore, "unstated requirements" can remain unstated not because users hold back or forget them, but rather because they are unaware of them. Users may have sensed something was wrong with the current software system in particular situations, but did not explicitly recognize it as a problem that could or should be addressed. Perhaps with additional information or after reflection, such users might come to realize and then express what it is that occurred that could have been prevented or mitigated. Unstated user and stakeholder needs can be a source for innovative system features and key architectural drivers and therefore can fundamentally impact the design, implementation, performance, and evolution of complex software systems. For example, the new iPhone 6 sports 64-bit computing on the new A8 chip (as did the previous generation iPhone 5S with its A7 chip) which might lead observers to ask, Why 64 bits? One reason might be: with the amount of random access memory (RAM) that exists in smartphones, we are approaching the maximum RAM storage possible for 32-bit computing, which is four gigabytes. By introducing 64-bit processors now, Apple may be positioning the broader iPhone ecosystem for 64-bit processing, setting the stage for an explosion of memory-intensive healthcare and home automation apps. Such forethought illustrates an appreciation for subtle longer-term needs that are best addressed early in the product (and in this case, product-line) lifecycle.  Prior research conducted by a team on which I participated foresaw an emerging need for requirements elicitation involving multiple and diverse parties proactively engaged in an early and ongoing conversations about the health of the ecosystem as a whole and for greater visibility into the goals, activities, and capabilities of various ecosystem participants. From such discussions, preventable problems can be identified and globally-sound and efficient solutions can be jointly-developed.  Our research team thus decided to initially focus on this research question:  Could existing requirements elicitation methods that address unstated needs be adapted to work across a geographically distributed community of users, stakeholders, and software developers? A Review of Existing Methods  Early in the project, then, our team conducted a literature review to determine which requirements elicitation methods had been investigated addressed unstated needs had potential for automation and analytic tool support  Most current requirements elicitation methods are specification-driven and do not address unstated needs. Those that do either do so directly by only targeting a small number of stakeholders and a small number of features (e.g., as in prototyping and simulation) or indirectly by analyzing user scenarios for a range of distinct user types (e.g., persona-based approaches). While other methods have some unique benefits, the team selected the KJ method, because of its systematic approach to eliciting and organizing user experience data with the goal of identifying potentially innovative new features and quality attributes. The KJ method is named after Jiro Kawakita, who originally conceived it, and consists of the following steps:  Step 1: Evaluate existing knowledge of requirements Step 2: Design open-ended probing questions Step 3: Conduct KJ interviews Step 4: Analyze output to form context need/activity statements Step 5: Conduct KJ affinitization Step 6: Identify unstated needs and candidate innovative solutions Step 7: Conduct Kano Analysis to determine must-be’s, satisfiers, delighters KJ is typically applied in co-located settings in a time-boxed fashion. Our research focused on enhancing KJ so that it works in a distributed environment—one in which not only users but requirements analysts and involved technologists are at different locations.  Challenges Several challenges are common to requirements elicitation methods and not necessarily unique to our work. During requirements elicitation, underrepresenting a key stakeholder does more than simply omit the immediate impact that the stakeholder could offer. That stakeholder may be focused on a cross-cutting concern (e.g., security, dependability, usability, etc.) that has important consequences for other stakeholders and end users. Stakeholders can include mid-stream suppliers to the product or system being developed and/or smaller niche solution providers—it is easy to overlook stakeholders that can be the source for innovative requirements. Another, more formidable, challenge that we encountered is that many requirements elicitation methods tend to be applied in co-located, time-boxed team settings, providing only one or two days to identify and analyze use cases or quality attribute scenarios. Such requirements elicitation methods tend to proceed in a lock-stepped, sequential fashion limited by the number of attendees that can be in one location, the range of perspectives that can be brought to bear and thus the comprehensiveness of the requirements analysis is limited. These sacrifices in scope and attention can result in an incomplete identification of key system requirements and priorities. For example, incompleteness can manifest itself as a lack of attention to critical security requirements because software developers easily overlook user motivations and limitations; trends in markets; or the emergence of new technologies that may negatively impact the system and its users and other stakeholders. There is also the concept of externalities, which occurs when stakeholders take a local action driven by a local perception of utility (value proposition) and fail to consider the extra expense that they cause other stakeholders who are not involved in the dialogue. It is important to step outside of that mind trap and consider the broader issues: Who is gaining? Who is losing? What is the real cost to society as a whole?  Failing to consider these broader issues can result in a compromised system where privacy can be lost and data breaches can occur, as seen from some of the deep dives undertaken as part of another recent research project. Finally, teams often suffer from group think, in which members fail to explore alternative or dissenting viewpoints to avoid creating conflict within the group. Without adopting a data-driven approach to requirements elicitation, requirements analysts can suffer from group think regarding what they perceive to be the primary needs of users and other stakeholders.  Current Status and Looking Ahead In recent months, we have completed the definition for our method, which we call "KJ+" and developed training and initial versions of the tools that support use of the method. KJ+ tackles each of the challenges noted: it can be applied in a distributed fashion and over a longer period of time, and thus is more inclusive than co-located, timeboxed approaches would be. Our method also proves to be more scalable than current approaches for the same reason. KJ+ inherits KJ’s focus on the unstated and unobvious, and because it is data-driven, it can mitigate the effects of group think.   In coming months, we plan to further pilot the method and compare its performance to results obtained using more traditional requirements elicitation approaches. Longer-term, we hope to have the opportunity to further research how we might augment or streamline the first few steps of KJ+ by automating analyses of user and developer discussion forums to identify more subtle and longer-term problems being encountered and thereby identify opportunities to improve the health of the STE. Such an approach might also support a more thorough discussion of externalities associated with particular solutions before they get broadly deployed. We welcome your feedback on our research. Please leave comments in the feedback section below.  Additional Resources To read the paper The KJ Method: A Technique for Analyzing Data Derived from Japanese Ethnology by Raymond Scupin, please visithttp://sfaa.metapress.com/content/x335923511444655/. To read the paper A Persona-Based Approach to Exploring Architecturally Significant Requirements by Jane Cleland-Huang, Adam Czauderna, and Ed Keenan please visit http://link.springer.com/chapter/10.1007%2F978-3-642-37422-7_2#page-1.  To learn more about KJ+, obtain a copy of the full-day tutorial presentation, Eliciting Unstated Requirements, which was presented in August 2014 at the IEEE International Requirements Engineering Conference, by visitinghttp://resources.sei.cmu.edu/library/asset-view.cfm?assetid=309174. 

Alison Price - Business Analyst During my time at DWP - a tad shy of three decades - I’ve seen a fair amount of change. In that time I’ve seen huge transformations in the way DWP customers apply for benefits and the impact of how their applications are processed. In the main though, applications have been clerical, on paper forms. When you think about it, that process is rather archaic, especially when we all do so many things online these days. So, with that in mind, on my last few projects, I’ve been learning how to deliver digital services. In my own DWP journey I’ve been involved in lots of projects, some better than others. So when I joined the Carer’s Allowance digital team in Preston earlier this year as a Business Analyst I welcomed a new challenge but; I wasn’t prepared for the way the work the team worked or how fast things moved. Learning, learning, learning The first couple of weeks were a bit like a doing a tricky jigsaw; putting the pieces together by shadowing the team to understand how they’d got to a Beta service, and how they managed and delivered the workload. It was during this time that I got a really good view of the work that was being done at Carer’s Allowance and the real difference that had been made in such a short time. I’ve had to learn very quickly. The digital service standard requires skilled multi-disciplinary team- so no pressure there then. I’m still learning and thoroughly enjoying it. The two-week sprint cycle is impressive and I work closely with the Valtech Business Analyst; we’re a proper Tweedledee and Tweedledum. Joking apart working with Steve Moody has helped me understand how my role helps every sprint happen. If I’m not writing user stories and acceptance criteria, I‘m maintaining the Kanban board, running workshops with the business, reviewing work or attending user-research days, preparing show and tell sessions… I could go on but you get the idea. My days are full on. Meeting user needs However, this isn’t about me. It’s about the service we give to our customers and how we improve that experience. Meeting user needs is not without its challenges. Take the subject of accessibility. It’s been a priority for the team and part of every sprint from the start. At first, this was all a bit perplexing. I had difficult conversations and lots of meetings to understand the Carer’s Allowance digital service could meet the DWP’s own accessibility standards. Initially it didn’t, so we compiled a detailed accessibility evaluation which we discussed with the Senior Responsible Officer who then approved the service. Not only does the way work we did ensure that we meet the digital service standard, it also helps us make a service that works on any device, any browser and with all the popular assistive technologies. We’re meeting user needs. It’s all about delivery All of these experiences have contributed to the sprints that followed. Right now, we’re replacing in-office printing with a service that allows more staff to access submitted claims. Because we’re delivering new releases at least every two weeks, we can quickly address any problems that come up. Needless to say the work the team are doing at Carer’s Allowance is, as I said at the start of my blog, amazing. I’ve been around for years and am used to change; but seeing it happen so rapidly and effectively is something else.

By Will Hayes  Senior Member of the Technical Staff Software Solutions Division  More and more, suppliers of software-reliant Department of Defense (DoD) systems are moving away from traditional waterfall development practices in favor of agile methods. As described in previous posts on this blog, agile methods are effective for shortening delivery cycles and managing costs. If the benefits of agile are to be realized effectively for the DoD, however, personnel responsible for overseeing software acquisitions must be fluent in metrics used to monitor these programs. This blog post highlights the results of an effort by researchers at the Carnegie Mellon University Software Engineering Institute to create a reference for personnel who oversee software development acquisition for major systems built by developers applying agile methods. This post also presents seven categories for tracking agile metrics.  An Empirical Approach to Software  Increasingly, the DoD and federal agencies procure software-intensive systems instead of building them with internal resources. However, acquisition programs frequently have difficulty meeting aggressive cost, schedule, and technical objectives. The research reported in this blog is part of our ongoing work to help acquisition professionals in the DoD adopt and use agile software development methods more effectively to overcome these challenges. Our latest research focuses on progress measurement and contractors, which extends our previous research examining selected DoD management and acquisition concerns, including information assurance.  Many program offices in government and military organizations that we support have found that their providers or contractors are adopting agile methods. These program offices have found new ways to deliver software products more rapidly and in smaller increments than is customary in these environments. Program offices struggle with these techniques, however, because they lack experience with the metrics required to gain insight on progress. There is an elaborate infrastructure and a fairly well understood set of definitions for measures traditionally used in that space.  When we examined what is written, trained, and discussed about the term agile, the focus tends to be on a team of seven plus or minus two individuals working together in a self-directed setting. These teams have a keen focus on value to the user and employ an empirical approach, but most of the discussion centers on the small team.  It is important to note that in Scrum, decisions are made based on observation and experimentation rather than on detailed upfront planning. Empirical process control relies on three main ideas: transparency, inspection, and adaptation.  Use of agile methods in the context of major DoD programs is not unprecedented. Until recently, however, publications and training courses have focused too narrowly on the development team. Our findings show that organizations that apply agile methods are doing a good job filling in those abstractions between the small team-focused measurement and what is needed at an enterprise or program level. So, one of the challenges to overcome then, is meeting the needs of large-scale-program-management without violating the environment necessary for a self-directed team to succeed using agile methods. In many medium-to-large sized organizations, measurement is often conducted at the request of another individual and typically an obligation imposed on one party to benefit another party. Far too often, people asked by team leaders and project managers to provide metrics get defensive. This dynamic may limit the value of agile methods, which are intended to serve as the basis for an empirical approach to software.  This empirical approach involves enacting Edward Deming’s plan-do-check-act-cycle, but at a much more immediate and individually focused level. This approach to software involves more frequent conversation among developers. Another hallmark of the approach is that those conversations are very focused on the product itself.  When viewed in the context of the Agile Manifesto and its 12 principles, the best way to demonstrate progress is to demonstrate capability: an actual working product in lieu of an abstraction on paper. Obviously, the product could not have been built without the abstractions, but in the context of agile methods, the focus is on demonstrable results and data collected by the team for its own use.  Agile Metrics For agile software development, one of the most important metrics is delivered business value. These progress measures, while observation-based, do not violate the team spirit. Our primary goal with this work was to help program managers measure progress more effectively. At the same time, we want teams to work in their own environment and use metrics specific to the team, while differentiating from metrics that are used at the program level. The technical report that we published on this topic—Agile Metrics: Progress Monitoring of Agile Contractors, which was co-authored by myself, Suzanne Miller, Mary Ann Lapham, Eileen Wrubel, and Timothy A. Chick—details three key views of agile team metrics that are typical of most implementations of agile methods:    Velocity. Simply stated, velocity is the volume of work accomplished in a specified period of time, by a given team. Typically, this is measured as story points accomplished per sprint. This measure is sometimes called "yesterday’s weather" by agile practitioners, as if to indicate its sensitivity to local conditions as well as seasonal trends. Indeed most experts explain that velocity is "team-unique" and thinking of this measure as a parameter in an estimating model is a mistake. The team must establish its own velocity for the work at hand.  Sprint Burn-Down Chart. As detailed in our technical note, this graphical technique provides a means for displaying progress for the development team during a sprint. As items in the backlog of work are completed, the chart displays the rate and amount of progress. This chart is typically provided for viewing on a team’s common wall, or electronic dashboard. Release Burn-Up Chart. A complementary graphical technique for the sprint burn-down, the release burn-up chart is also commonly used. Many cling to the convention that sprints burn down and releases burn up—though there is no mathematical principle that governs this choice. With each completed sprint, the delivered functionality grows, and the release burn-up chart depicts this progress in an intuitively logical fashion. This concept makes use of workflow management tools and other extensions of the concept. Our research involved interviewing professionals who manage agile contracts who gave us insight from professionals in the field who have successfully worked with agile suppliers in DoD acquisitions.  Based on our interviews with personnel who manage agile contracts, our technical note identified seven successful ways to monitor progress that help programs account for the regulatory requirements that are common in the DoD:  Software Size is typically represented in story points when agile methods are used. This approach is supported by the decomposition of functionality from a user’s perspective—into user stories. Tracing these user stories to system capabilities and functions, a hierarchy within the work can be meaningfully communicated and progress monitoring based on delivered functionality will focus on utility and function—rather than proxies like lines of code or function points. Effort and Staffing must be tracked because they tend to be the primary cost drivers in knowledge-intensive work. Use of agile methods will not change this fundamental fact, nor will it be necessary to make major changes to the mechanisms used to monitor progress. What does change, however, is the expected pattern of staff utilization. With the steady cadence of an integrated development team, the ebb and flow of labor in specialized staff categories is less prevalent when using agile methods. In general, agile teams are expected to have the full complement of needed skills within the development team—though some specialized skills may be included as part time members on the team. Rules of thumb applied in monitoring this element of performance on a contract must be revised. The expectation of a slow ramp-up in staffing during the early phases of a development effort may be problematic, and plans for declining use of development staff during the last half of the program (when testing activities traditionally take over) must be recalibrated. Organizations may establish test teams to perform system testing or regression testing outside the context of the development team. Schedule is traditionally viewed as a consequence of the pace of work performed. In agile development, the intent is to fix this variable, and work to maximize performance of the development team within well-defined time boxes. This places important requirements on stakeholders who must communicate the requirements and participate in prioritization of the work to be performed. Quality and Customer Satisfaction is an area where agile methods provide greater opportunity for insight than traditional development approaches tend to allow. The focus on frequent delivery of working software engages the customer in looking at the product itself, rather than the intermediate work products like requirements specifications and design documents. A strong focus on verification criteria (frequently called "definition of done") sharpens the understanding of needed functionality, and attributes of the product that are important to the customer. Cost and Funding structures can be tailored to leverage the iterative nature of agile methods. Using optional contract funding lines or indefinite delivery indefinite quantity (IDIQ) contract structures can add flexibility in planning and managing the work of the development organization. A more detailed discussion of the considerations for contracting structures to handle this is the subject of an upcoming publication. Requirements are often expressed very differently in the context of agile development—in contrast to traditional large-scale waterfall development approaches. A detailed and complete requirements specification document (as defined in DoD parlance) is not typically viewed as a prerequisite to the start of development activities when agile methods are employed. However, the flexibility to clarify, elaborate and re-prioritize requirements, represented as user stories, may prove advantageous for many large programs. The cost of changing requirements is often seen in ripple effects across the series of intermediate work products that must be maintained in traditional approaches. The fast-paced incremental approach that typifies agile development can help reduce the level of rework. Delivery and Progress monitoring is the area where perhaps the greatest difference is seen in agile development, compared to traditional approaches. The frequent delivery of working (potentially shippable) software products renders a more direct view of progress than is typically apparent through examination of intermediate work products. Demonstrations of system capabilities allow early opportunities to refine the final product, and to assure that the development team is moving toward the desired technical performance—not just to ask whether they will complete on schedule and within budget.  Looking Ahead  We continue to learn new and inventive ways of demonstrating progress and diagnosing performance from agile implementers. The value of this approach is that it represents a narrative driven by real-world experience.  Through this research, we have also observed that agile teams don’t want to wait for data analysis. Future research needs to focus on earlier analysis of data streams. The graphical representations needed to analyze these data streams are not the traditional ones we have seen. The analysis techniques that need to be applied, as well as the available baselines, take on a different form in this context: more near-term, more immediate feedback and the intelligent use of historical baselines.  Additional Resources Acquisition researchers in the SEI’s Software Solutions Division have published several technical notes that address different topics of interest to acquisition professionals that are contemplating or are currently using agile methods as part of their acquisition:  Agile Metrics: Progress Monitoring of Agile Contractorshttp://resources.sei.cmu.edu/library/asset-view.cfm?assetid=77747 Considerations for Using Agile in DoD Acquisitionhttp://www.sei.cmu.edu/library/abstracts/reports/10tn002.cfm Agile Methods: Selected DoD Management and Acquisition Concernshttp://www.sei.cmu.edu/library/abstracts/reports/11tn002.cfm A Closer Look at 804: A Summary of Considerations for DoD Program Managershttp://www.sei.cmu.edu/library/abstracts/reports/11sr015.cfm DoD Information Assurance and Agile: Challenges and Recommendations Gathered Through Interviews with Agile Program Managers and DoD Accreditation Reviewershttp://www.sei.cmu.edu/library/abstracts/reports/12tn024.cfm Parallel Worlds: Agile and Waterfall Differences and Similaritieshttp://resources.sei.cmu.edu/library/asset-view.cfm?AssetID=62901  

  Why do so many people get so excited over an HR conference?    Because SHRM is known for producing some of the most informative and engaging conferences in the world, and the SHRM Annual Conference & Exposition, which starts at the end of June, is on every HR professional’s bucket list.  As thousands of excited attendees prepare to travel to Las Vegas for the conference, June 28-July 1, the Society is working hard to deliver another amazing experience.  Once again, SHRM will have a robust social media presence during the conference under the #SHRM15 hashtag and...

At the recent Civil Service Live events we had lots of people coming to our stand wanting to find out more about the DWP Digital Academy and how we are building digital capability within DWP. In the spirit of "showing the thing" we have made a short film to give an insight into what’s happening at our Digital Academy and how we are building our in-house digital capability. If you are unable to view the film you can email me to request a transcript. You can follow us on Twitter @DigitalDWP.

By Andrew P. Moore Lead Researcher CERT Insider Threat Team  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.  A Pattern-based Approach to Insider Threat  This post is the latest installment in an ongoing series describing our research to create and validate an insider threat mitigation pattern language to help organizations prevent, detect, and respond to insider threats. As described in a previous post, our research is based upon our database of more than 700 insider threat cases and interviews with the United States Secret Service, victims’ organizations, and convicted felons. From that database, we identified 26 patterns that capture reusable solutions to recurring problems associated with insider threat. Insider threat mitigation patterns are organizational patterns that involve the full scope of enterprise architecture concerns, including people, processes, technology, and facilities. This broad scope is necessary because insiders often have authorized access—both online and physical—to organizational systems. Our approach acknowledges inter-relationships between organizational structures, such as policy, training, and employee and policy agreements, and draws upon those inter-relationships to describe the patterns themselves.  The following is a high-level outline of a pattern for disabling access after an insider leaves an organization for other employment, an older version of which was published at the 2013 PLOP Workshop: Title: Eliminate Methods of Access after DepartureIntent: To avoid insider theft of information or sabotage of information technology after departureContext: An insider is departing an organization for employment elsewhere and you have a comprehensive record of access paths the insider has for accessing the organization’s systemsProblem: Insiders who depart an organization under problematic circumstances may become angry to the point of wanting to steal information from the organization or compromise the integrity of the organization’s information or information systems. Active access paths into the organization’s systems after departure provide the opportunity to do that.Solution: Disable accounts that you know about upon departure, and prepare to monitor suspicious remote access after departure for signs of unauthorized access attemptsRelated Patterns: Monitor Activity after Departure  For organizations and agencies establishing insider threat programs, our approach specifies what processes are important and stresses the need for consistent enforcement what policies are important how those processes and policies are implemented both by humans and technology what technology is needed to support all of that  There will undoubtedly be great variation in insider threat programs, depending on the risks faced by individual organizations. We therefore use capability development scenarios to designate paths through the mitigation pattern language with the goal of mitigating a specific insider threat behavior. The mitigation pattern outlined above will be used in a capability development scenario described below. Such capability development scenarios serve to guide insider threat program designers as they try to ensure their programs are resilient against insider threats to their critical assets.  An Example Capability Development Scenario In a forthcoming report on this topic, we will outline several capability development scenarios (CDSs). One scenario involves mitigating theft of intellectual property when an employee resigns or is fired from the organization: Through our analysis of our insider threat database, we observed that 70 percent of insiders who stole intellectual property from an employer did so within 60 days of their termination from an organization.  This CDS urges that both parties must agree at employee hiring regarding the ownership of intellectual property as well as the consequences if the agreement is breached. Upon termination, whether voluntary or forced, the organization should disable insider’s accesses. During the exit interview, the organization must review existing agreements regarding IP.  The CDS advocates that an employer monitor insider actions 60 days prior to termination and for 60 days after termination. Suspicious behaviors including uncharacteristically large downloads of intellectual property should be handled either by the human resources or legal departments or a combination of both.  As specified by the associated path through the mitigation pattern language, this CDS advocates that organizations  Screen Employees Agree on IP Ownership Periodically Raise Security Awareness Log Employee Actions Increase Monitoring Due to an Employee’s Pending Departure Reconfirm Employee Agreements on Departure Eliminate Methods of Access after Departure Monitor Activity after Departure  In summary, mitigating theft of IP at departure involves ensuring that the organization increases their monitoring of any insider with access to critical assets for specific suspicious behaviors when the insider resigns or is terminated. In addition, the insider must agree to and be reminded that they can’t take organization-owned IP with them.  Future Work in Insider Threat  Continuing our efforts to help federal agencies and contractors develop insider threat programs, per executive order 13587, we are now seeking active government partners to apply and refine our approach. We also are continuing our research into fundamental patterns of insider threat mitigation to make sure that they remain well grounded and validated scientifically.  Looking ahead, we plan next to investigate insider social networks and the role they play in contributing to insider threat. In particular, we plan to examine how those social networks change over time to determine whether we can distinguish the social networks of malicious and non-malicious insiders. As part of this research, we are collaborating with Dr. Kathleen Carley, a professor at Carnegie Mellon University’s Institute for Software Research in the School of Computer Science. We welcome your feedback on our work in the comments section below.  Additional Resources To read the about insider threat mitigation patterns published at PLoP, please visit http://www.hillside.net/plop/2013/papers/Group4/plop13_preprint_47.pdf. To read the PLoP Conference paper, Building a Multidimensional Pattern Language for Insider Threats, please visit: http://www.hillside.net/plop/2012/papers/Group%202%20-%20Rattlesnake/Building%20a%20Multidimensional%20Pattern%20Language%20for%20Insider%20Threats.pdf. To read the SEI technical report, Justification of a Pattern for Detecting Intellectual Property Theft by Departing Insiders, please visithttp://www.sei.cmu.edu/reports/13tn013.pdf. For more information about the CERT Insider Threat Center, please visithttp://www.cert.org/insider-threat/. 

Ben Holliday - User Researcher Back in December, Amy wrote on the GDS design notes blog about start pages within guides: Lots of users navigate to start pages for services through content on GOV.UK, which means start pages repeat information they may already have read Since then we’ve been working on improving the Carer’s Allowance content on GOV.UK - testing different design iterations in user research sessions. What we discovered in research In our user research, we discovered 2 clear user needs for the Carer’s Allowance guide on GOV.UK. Users want to know: what they’re entitled to, and/or where and how to apply We found that the amount of content about Carer’s Allowance on GOV.UK can be overwhelming so many people just want to start an application. We also found that most people have common questions about whether they, their partner, or the person they care for, will be better or worse off if they get Carer’s Allowance. Some users need detailed information, but most want a service that "just tells me what I need to know". This is why people often prefer to speak to someone - they can get the information they need without having to read through everything. Getting users to what they want quicker We’ve now implemented the design for a single ‘make a claim’ page in the guide. There’s no longer a separate start page so users can navigate more clearly to ‘Apply now’. It means they can quickly find out if they are entitled to Carer’s Allowance by answering the eligibility questions in the application and access a helpline if they still need to speak to someone. The old Carer’s Allowance guide was more digital?by?preference, than default. The new ‘make a claim’ page has more emphasis on the digital service because it’s simpler, clearer and faster to apply online. Improving content After testing different approaches for ‘you will need’ we found that we should just tell people about anything that could block their progress. For example, you need your National Insurance number or you can’t complete the transaction. In contrast, we previously said ‘details of benefits received’ but you only need to know that benefits are being received - you don’t need the details to enter. We also found that eligibility needs to be signposted, but it doesn’t need to be part of ‘make a claim’. If people just want to start an application they then answer the eligibility questions. What’s happened These changes have now been live on GOV.UK since May. We’ve seen a significant increase in traffic to the service and a 22% increase in applications made online. More people than ever before are using the online service. Next steps We’re still testing and learning about the content in ‘make a claim’. Most of our research is now with less confident users who need reassurance that completing an application online is quick, easy and secure. We’re thinking about: Telling people that they don’t need a printer ? staff that speak to customers in the Carers Allowance Unit regularly hear that people expect to have to print to use the online service Telling people how long it will take them to complete an application online (using live data) Showing users the user satisfaction score for the Carer’s Allowance online claim service  

By Julien Delange Member of the Technical StaffSoftware Solutions Division 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.  An Approach to Improve Safety-Critical Process Development At the ERTSS 2014 conference in February 2014, Jerome Hugues from Institut Supérieur de l’Aéronautique et de l’Espace (ISAE) and Matteo Bordin from AdaCore presented an approach that completely generates a system implementation from models. Their approach relies on various notations—including AADL and Simulink—to capture the different system aspects, such as architecture and behavior. This work is the result of a collaboration between a university (ISAE) and a company (AdaCore) that are both experts in the design and implementation of safety-critical systems. After the conference, I had the opportunity to discuss the project with Cyrille Comar, the cofounder of AdaCore, and Matteo Bordin, a model-based expert at AdaCore, and learn more about this work.  Their approach integrates two different modeling notations to capture system concerns: The architecture is specified using AADL. This architecture defines the execution environment, software deployment, and configuration and includes the number of tasks, allocation to a processor, binding of a connection on a specific bus to transport data, and other specifications. Some people relate to this view as the so-called nonfunctional architecture (how the system provides its functions). The behavior is specified using Simulink, which characterizes how the system processes and uses the data from its environment, for example, to compute new data or activate a device. Some relate to this view as the functional architecture (what functions the system provides). These two notations are fully integrated: the architecture is the execution support for the behavior. To integrate behavior models, the architecture (the AADL model) contains components (subprograms) that reference the behavior and allocate the functional components into the execution platform. Figure 1 - Code Generation Process from AADL The ISAE-AdaCore team developed tools—including Ocarina and Project P—that generate and integrate code from AADL and Simulink. Once the tools have generated the code, compilers can link the code together without modification, creating the complete implementation and avoiding any errors related to manual code development. Such an approach removes an important error contributor (i.e., human developers) and is a major step toward improving safety-critical process development. Why Automate Code Production? This work relies on AADL because it provides the appropriate semantics to generate code, as Bordin, project manager at AdaCore, explained to me after the conference: AADL has the main advantage of providing a blueprint representation of a runtime system. This allows translating models to source code without ambiguities and ensures that no semantics are lost during code generation. Of course, the availability of Ocarina was a major plus in choosing AADL. During our discussion, Bordin also reported that the precise semantics of the language avoids the ambiguity of having multiple notations and diagrams for the same concept:   For this specific project, the only other off-the-shelf alternative would have been OMG MARTE. The main issue we have with MARTE is the ambiguity in representing runtime elements—they can be RtUnit, SwSchedulableResources, etc. Each MARTE tool requires one specific modeling pattern to work. Some tools may require composite structure diagrams, others may require activity diagrams, and others may require sequence diagrams. This means that it is difficult for application developers to easily adapt their modeling standard to tools. In addition, in MARTE it would have been necessary to define our own library of model elements to represent our core building blocks (Ada Ravenscar Tasks), while in AADL it is enough to specify precise properties to achieve the same result. Finally, we are not aware of MARTE-to-SPARK code generators, and we believe SPARK is a major element in our approach. The development process described above relies on the architecture model as the central artifact for almost all activities (design, validation, analysis, and implementation). For that reason, the selected modeling language must support an accurate and precise semantics to avoid any ambiguity. This is why AADL is appropriate to fill this need. The study by Bordin  and Hugues also shows the relevance of model-based technology and especially AADL through a use case in a production project. A recent paper presented at the 35th International Conference on Software Engineering (ICSE) reported that more than half of developers do not have a real interest in modeling technology, mostly because of concerns with model consistency. For example, one architecture aspect (waiting time on a shared resource) can be represented using different patterns, each one having different and inconsistent characteristics (the timeout to wait for the resource). By using a single notation for driving different aspects of system development (such as validation and implementation), AADL addresses this issue and ensures system consistency (e.g., having the same timeout value) across the development process. Toward an Optimized System Implementation The research described in this post is a great step forward in the adoption of model-based tools in operational projects and shows the readiness of model-based methods to automate the implementation of safety-critical systems. By using a full model-based approach from system design to implementation, these tools ensure that validated requirements are preserved throughout the development process and then are correctly implemented. In addition, system stakeholders can leverage model analysis techniques not only to detect potential architecture defects earlier in the design process but also to optimize the architecture and produce simpler, lighter, and more efficient implementations. In particular, adding a new step in the implementation process, as shown in the figure below, to optimize the architecture by removing useless components or refactoring their interactions would simplify the system implementation and ease its certification. As shown below, the initial model would be processed and automatically optimized by the code generator, creating a more efficient system implementation. For example, if two interdependent tasks are executed on the same processor, one potential optimization would consist of relocating them into one process, removing overhead resources and other related context-switch times during execution. Of course, optimizations would be relevant based on stakeholders’ requirements. For example, relocating both tasks within the same process might improve system performance but might be an issue from a security perspective if they contain data at different security levels. Figure 2 - Optimized Architecture Generation By using a high-level notation that focuses on a system’s key quality attributes (e.g., performance, safety, etc.), appropriate tools can analyze the system architecture and optimize it. To achieve such optimization, an accurate semantics—such as the one from AADL, with its specialized components types and properties—is a must. AADL provides the appropriate level of abstraction to simplify the system and eventually its implementation. Conclusion The research described above demonstrates that system implementation can be automatically generated from models. Although code generation techniques from models are not new (generation of code skeletons in Java from UML models has existed for several years), this new ISAE-AdaCore project automatically produces a complete system implementation, avoiding errors related to manual code production and potentially improving the certification process. Model-driven engineering techniques not only help to implement a system but also automatically improve it. By analyzing the architecture, tools can optimize and simplify the system, making the resulting implementation lighter and easier to analyze and certify. Ongoing SEI research efforts will focus on such optimizations techniques to remove some of the usual system complexity and ease the verification and certification of system implementation. Additional Resources  For more information about the Architecture Analysis & Design Language (AADL) please visithttp://www.aadl.info/aadl/currentsite/. For more information about the Embedded Realtime Software and Systems Conference (ERTS), please visit http://www.erts2014.org/. For more information about UML in Practice, please visithttp://oro.open.ac.uk/35805/. To read the paper, System to Software Integrity: A Case Study, please visithttp://www.spark-2014.org/entries/detail/case-study-for-system-to-software-integrity-includes-spark-2014.  To view a recent webinar, Architecture Analysis with AADL, please visithttps://www.webcaster4.com/Webcast/Page/139/5357. 

Starting Wednesday, May 13th, through Friday, May 15th, the SHRM Foundation is giving away books you'll enjoy reading next to the pool this summer. To be eligible to win, enter daily by completing these two steps below: 1. Share the title your favorite HR book2. Donate $35 or more to the SHRM Foundation online   The SHRM Foundation will select five winners each day below who have submitted the most creative HR book title to win! Each day, we're giving...

By Aaron Ballman Senior Member of the Technical StaffCERT Secure Coding InitiativeWith 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 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. Foundations of Our Work Many programmers today typically take a lock-based approach to dealing with concurrency issues. Typically, the canonical lock-based approach involves locking a piece of memory to ensure only one thread at a time can access a given region of memory. Then, when that piece of memory no longer requires protection, it is unlocked. Attempts to access that memory by threads not holding the lock result in those threads blocking until the lock is released. There are certain classes of problems, however, where a lock-based approach does not make sense, including real-time systems and interactions between the graphical user interface (GUI) and synchronous resources, such as a database or the network. Real-time systems typically avoid locks because with locked resources, the potential exists for threads to block while waiting for a lock to be released. If a critical thread is blocked (like the thrusters for a jet), the resulting behavior of the system could be disastrous. Likewise, is it often desirable to avoid using locks from the GUI thread. If the GUI thread is blocked, the user interface cannot be updated and no new user input can be accepted until the GUI thread is released from its blocking operation. As detailed in our introductory blog post on this work, which was spearheaded by Dean Sutherland, our approach is predicated on thread usage policy (the subject of Sutherland’s doctoral thesis) to address the locking problem described above. That blog post defined thread usage policy as a group of often unspecified preconditions used to manage access to a shared state by regulating which specific threads are permitted to execute particular code segments or to particular data fields. Put another way, instead of locking regions of memory, a programmer specifies that threads have roles to fulfill. Roles are associated with methods. Specifically, a programmer declares that a particular method should only be called from a thread context that is explicitly holding or not holding a specific role. For example, the main thread in a program is typically used to run the GUI for the program, so a programmer could assign the main thread a "GUI" role. A worker thread could be spawned off to handle database access, and that thread could be assigned a "Database" role. Finally, the programmer can use an annotation that specifies "may only be called when the ‘Database’ role is held." If the programmer wrote code that would attempt to access the database by calling the "Database" annotated function from a GUI function, a diagnostic would be generated alerting the programmer of this constraint violation. The concept of thread usage policy is not language specific; similar concepts exist in many programming languages including Java, C, C#, C++, Objective-C, and Ada. The initial post on this work described its application to Java. This post will describe my effort with Dean Sutherland, along with collaborator DeLesley Hutchins of Google, to take the thread usage policy initially applied in Java and transfer it to C and C++ using the Clang open source compiler. Collaborating with Google As our team of researchers began implementing our approach, we learned that a thread safety analysis based on locks had already been developed by Google, and deployed on a large scale within their internal code base. The Google code base makes heavy use of locks, and they have developed both static analysis tools, and dynamic analysis tools such as Thread Sanitizer, to help find and prevent race conditions. Working with DeLesley Hutchins, we came to the conclusion that although locks and roles are orthogonal ways of ensuring thread safety, they can both be handled using the same underlying static analysis machinery. The primary difference between the two approaches lies in the terminology that programmers use to annotate their programs. When we began this collaboration, Google had already mandated that all programmers use lock-based analysis on every line of C++ code that is run within Google. An Overview of Our Analysis Technique Compilers with static analysis functionality, such as Clang, have helped developers by allowing threading policies to be formally specified and mechanically checked. Clang is a production quality, open source compiler for the C family of programming languages that builds on the LLVM optimizer and code generator. Clang also provides a sophisticated infrastructure for implementing warnings and static analysis. We selected Clang because it initially parses a C++ input file to an abstract syntax tree (AST), which is an accurate representation of the original source code, down to the location parentheses. The AST makes it easier to emit quality diagnostics, but complicates analysis in other respects. As described in our paper, the Clang analysis infrastructure constructs a control flow graph (CFG) for each function in the AST. This transformation is not a lowering step; each statement in the CFG points back to the AST node that created it. We are then able to walk the CFG, building a contextual set of roles currently held or not held, and compare them against assumptions annotated in the source code to diagnose incorrect assumptions. Due to working within a higher-level abstraction layer, the diagnostics we report to the user closely map to their actual source code, but we are still capable of producing diagnostics for compiler-generated code, such as implicitly-defined constructors in C++. You can annotate your source with thread roles for analysis with Clang by using the capability attributes provided by the compiler (the full list can be found in the Clang documentation). You start by defining role types using the capability or shared_capability attributes and pass "role" as the argument. This attribute appertains to a struct or typedef, which can then be used to declare unique roles for use within your source code. For example, if a programmer wanted to declare two thread roles, FlightControl and Logging, for a C program, they would be introduced as: typedef int __attribute__((capability("role"))) ThreadRole;ThreadRole FlightControl, Logging; These two distinct thread roles can then be used to identify those capabilities for use in the other capability attributes. Since thread roles do not define semantic functionality at runtime, the acquisition and forfeiture of a thread role capability is typically defined as a noop which does not require additional thread safety analysis checking, and is optimized away by the compiler, requiring no runtime overhead: void acquire(ThreadRole R) __attribute__((acquire_capability(R))) __attribute__((no_thread_safety_analysis)) {}void release(ThreadRole R) __attribute__((release_capability(R))) __attribute__((no_thread_safety_analysis)) {} These functions can then be used to acquire or release the given thread role. Once the acquire() function is called, the capability passed in to the function will then be held for the capability context of all subsequent function calls, until the release() function is called with that capability. For instance, the logging thread’s entry point may look like: void *logging_entrypoint(void *arg) {  void *ret;  acquire(Logging);  ret = logging_entrypoint_impl(arg);  release(Logging);  return ret;} The thread entry point acquires the Logging role, calls the actual implementation of the logging thread with the Logging capability held, and then releases the Logging role before the thread completes execution. The FlightControl thread entry point would look similar, except it would acquire and release the FlightControl capability instead of the Logging capability. At this point, it is now possible to usefully annotate functions as requiring either the Logging or the FlightControl capability. If these functions are called from a context where the capability set satisfies the requirements written on the function, no diagnostic is produced because the source code is logically consistent with the annotations. For instance, the following definition of the logging_entrypoint_impl() function demonstrates requiring the Logging capability in a well-formed manner: extern void dispatch_log(const char *msg) __attribute__((requires_capability(Logger)));extern const char *deque_log_msg(void) __attribute__((requires_capability(Logger)));void *logging_entrypoint_impl(void *) __attribute__((requires_capability(Logger))) {  const char *msg;  while ((msg = deque_log_msg())) {    dispatch_log(msg);  }  return 0;} However, if a function is called from a context where the capability set does not satisfy its requirements, a diagnostic is produced at compile time. Consider this definition of the flight_control_entrypoint_impl() function: void *flight_control_entrypoint_impl(void *) __attribute__((requires_capability(FlightControl))) {  dispatch_log("Flight Control Started"); /* Should diagnose an error */  /* … */  return 0;} In this example, flight_control_entrypoint_impl() requires that the FlightControl capability be held, which is successful due to the implied implementation of the thread entrypoint acquiring the FlightControl role. However, the call to dispatch_log() requires the Logging capability be held, which it is not from within this call graph, and so a diagnostic is issued. A Calculus of Capabilities As described in our recently published paper on this work, C/C++ Thread Safety Analysis, Clang’s thread safety analysis is based on a calculus of capabilities. To read or write to a particular location in memory, a thread must have the capability, or permission, to do so. A capability can be thought of as an unforgeable key or token, which the thread must present to perform the read or write. Capabilities can take one of two forms: A unique capability cannot be copied, so only one thread can hold the capability at any one time. A shared capability may have multiple copies that are shared among multiple threads. Uniqueness is enforced by a linear type system. The analysis enforces a single-writer/multiple-reader discipline. Writing to a guarded location requires a unique capability. Likewise, reading from a guarded location requires either a unique or shared capability. In other words, many threads can read from a location at the same time because they can share the capability, but only one thread can write to it. Moreover, a thread cannot write to a memory location at the same time that another thread is reading from it because a capability cannot be both shared and unique at the same time. This discipline ensures that programs are free of data races, which are a situation that occurs when multiple threads attempt to access the same location in memory at the same time, and at least one of the accesses is a write. Since write operations require a unique capability, no other thread can access the memory location at that time. Wrapping Up The destructive nature of race conditions means that many organizations use both static analysis and dynamic analysis in multi-threaded programs, similar to Google. While these tools complement each other, dynamic analysis operates without annotations and thus can be applied more widely. Dynamic analysis, however, can only detect race conditions in the subset of program executions that occur in test code. Static analysis has proved to be less flexible, but covers all possible program executions. Static analysis also reports errors earlier, i.e., at compile time.We encourage readers to use these annotations by downloading the latest version of Clang (3.5) and trying them out. Please send us feedback on your experiences as well as feedback on the research described above in the comments section below. Additional Resources To download the paper, C/C++ Thread Safety Analysis, please visithttp://static.googleusercontent.com/media/research.google.com/en/us/pubs/archive/42958.pdf. To read the paper, Composable Thread Coloring (which was an earlier name for the technique we now call thread role analysis) by Dean Sutherland and Bill Scherlis, please go towww.fluid.cs.cmu.edu:8080/Fluid/fluid-publications/p233-sutherland.pdf.