Ben Holliday - Head of User Experience Design As part of our digital transformation we’re looking for people to work with us in new digital design roles. Our aim is to build DWP digital services for GOV.UK that are so good, people prefer to use them over the alternatives. To achieve this we need to design solutions that meet user needs. These roles we’ve created are all an essential part of this process: Interaction Designers Content Designers Front End Developers While these roles aren’t completely new to the department, we’re now building a design team with these specialist skills. Not only will these people work separately within our different project teams, they’ll also be working together. This is essential as we focus less on products and more on services that create a consistent user experience when people interact with DWP throughout their lives. What we mean by ‘user experience’ and ‘design’ When we talk about ‘design’, we’re not talking about how things look. Design is the process we use to solve problems and make things work - it helps us understand and deal with the complexity of government in order to deliver services. These services should work well for the people that use them - they should meet their needs, or simply help them to get on with their lives. We believe that ‘user-centred’ or ‘user experience’ (UX) design isn’t, and shouldn’t be seen as, an exclusive job role. The user experience of our services is ultimately the result of the decisions and the work of an entire team. This is what why we’re building capability through our DWP Digital Academy, equipping multi-disciplinary teams to work together to design and deliver digital services. We can’t ignore the realities of business or policy, so having digital design specialists on each of these teams helps us find solutions when we face difficult product decisions - resolving the tension between user needs and the constraints we’re working with. How we deliver services to meet user needs We work using agile methods and try to make sure all our teams have an Interaction Designer and Content Designer working closely together with User Researchers on every project. Interaction Designers focus on all aspects of the service that directly affect the end experience of users. They care about each of the individual interactions within a user interface, but also understand and influence how interactions shape user journeys across one or multiple channels. Interaction Designers will work with Front End Developers - both of these roles focus on creating prototypes that enable us to regularly test our work with real users. We also have specialist roles for Content Designers. Almost everything we design is content - from explaining benefit entitlement to writing clear and concise content that helps people use our digital services. Content Designers are as comfortable writing long-form as they are labelling individual form fields. I briefly mentioned Front End Developers. They’re also part of every project and help us build and test user journeys, working in real code as soon as possible. As well as prototyping, they work with other Developers as services progress through Alpha, and Beta, moving into more technical environments as projects progress. Interested in joining us? All the roles we’re currently advertising will be based at one of our digital hubs in London, Leeds, or Newcastle working on a range of new and existing digital projects. Visit the individual job listings or Civil Service Jobs for more information. These roles close on January 16th.

By Julien DelangeMember of the Technical StaffSoftware Solutions Division Over the years, software architects and developers have designed many methods and metrics to evaluate software complexity and its impact on quality attributes, such as maintainability, quality, and performance. Existing studies and experiences have shown that highly complex systems are harder to understand, maintain, and upgrade. Managing software complexity is therefore useful, especially for software that must be maintained for many years. To generate the complexity metrics, tools extract applicable data—such as source lines of code, cohesion, coupling, and more—from binary or source code to analyze the software and report its complexity and quality. Several tools support these techniques and help stakeholders manage the evolution of system development, provide quality improvements, prevent lack of cohesion, and perform other tasks. To date, such approaches have been successfully used in many projects, but as system development moves toward model-based engineering, these methods, metrics, and tools might not be sufficient to manage model complexity. This blog post details the state of the art for reporting model complexity and introduces research underway at the SEI in this area. Complexity and Model-Based Engineering In the domain of embedded systems, projects are increasingly adopting model-based engineering tools, such as SCADE or Simulink, to specify and capture the functional architecture. Thanks to code generators, the bulk of these systems are no longer implemented manually, but instead are generated automatically from models. Code is then created from these abstract representations, with the result that code metrics no longer match engineering efforts. A simple change on a single model component can modify hundreds of lines of code, and modifying hundreds of model components might have little impact on the generated code. In fact, changes in the model are not always proportional to source code changes. For these reasons, code-analysis techniques (at the binary- or source-code level) cannot be used, and new methods must be developed to evaluate the quality and complexity of these auto-generated models. These issues have been studied for several years, and interest in the topic continues to grow. Some work has focused on mapping existing source-code metrics (for example, Halstead  or the cyclomatic complexity) approaches to models (as in the research by Jeevan Prabhu), whereas others have proposed new metrics (such as the structure, data complexity, or the component instability as defined by Marta Olszewska). Regardless of the selected technique, the goal is to analyze the impact of a change and overall quality of the model by analyzing various aspects, such as the number of blocks, number of connections, nesting level, and definition of data types. Tools also report metrics from the models—for example, sldiagnostics and its front-end report metrics of Simulink models.  Reducing Complexity of Models As model-based systems evolve, they are modified, updated, and integrated with more components. Moreover, as more functions are now implemented using software, models become more complex (with many inter-connected components that have potentially conflicting requirements), which makes their verification, analysis, and maintenance harder. For these reasons, detecting system complexity as early as possible can help developers manage it and keep it below a critical threshold. The existing tools mentioned previously help designers by producing a single value that reflects the quality and complexity of a system. Hence, they are useful to manage system evolution. However, these tools do not detail how to reduce complexity and improve system quality. On the other hand, reducing complexity and improving system quality is the goal of having these metrics: ultimately, system stakeholders want to keep the quality of system artifacts under control and fix potential defects or reduce sources of complexity. Among the contributors to complexity, a correct use of data types is particularly important. For example, to specify a command to an actuator, using an enumerated type with restricted values is more accurate than using a generic type (such as an integer). This might impact system quality and makes system analysis, testing and certification more difficult than when using restricted type (which can reduce the system state space). On the other hand, many models rely intensively on generic types, such as Boolean or integer, which are not appropriate when data values are limited, as with a system state or the value of a command. Modeling guidelines recommend using enumerated types as much as possible, but engineers don’t often do so, and the resulting models lack data abstraction and incur system complexity (such as an increasing number of interfaces or states). For example, consider a system with a component representing a door sensor sending the actual status (open or closed). Developers could take different implementation strategies: Using Boolean types: The block will send the status using two Boolean variables—one to indicate that the door is open, the other to indicate that the door is closed. Using enumerated types: The block will send the status using a single variable that indicates the status (open or closed). Using the first method, both variables can be true, meaning that the door can be open and closed at the same time. Using the second method reduces the block complexity: it reduces the number of variables by 50 percent, and it ensures consistency because the sensor can report only one possible status. Using appropriate data abstraction provides many other benefits (such as strong type checking) and will definitively help engineers to reduce complexity and avoid errors. Applying such abstraction on real systems with hundreds of variables might not reduce system complexity by half, but it will have a significant impact. Our Approach  The SEI is dedicated to helping organizations manage software complexity more effectively, especially for systems that must be maintained and upgraded over years, such as those in the avionics, aerospace or automotive domains. So far in this post, I have detailed the state of the art for reporting model complexity. I will conclude by introducing research now underway at the SEI to address the issue of managing model complexity. As more developers of embedded systems adopt model-based methods, avoiding complexity as early as possible ensures that it does not propagate through the development process. I am collaborating with a group of SEI researchers who are actively working to identify the root cause of complexity in models and propose design alternatives to reduce complexity and improve system quality. The project will propose an approach to qualify and quantify complexity in models, ideally leveraging existing metrics and applying them in models while trying to propose solutions to re-design the system and adopt modeling patterns that will avoid complexity. Our work will focus on using existing metrics (such as the Cyclomatic Complexity) on models but also find new ones to detect emerging complexity. For example, one idea is to focus on data abstraction (e.g., using enumerated types rather than generic ones, as explained previously). These metrics will then be reused by tools to help system designers propose implementation alternatives that avoid this complexity. Through earlier detection of emerging model complexity our research aims to ensure that the issues related with complexity, such as rework costs and finding issues late in the development process, will not be propagated through the development process. Over the long term, it would reduce re-engineering efforts and costs associated with maintenance and testing activities. We welcome your feedback on our research in the comments section below.  Additional Resources To read the paper, Simulink-Specific Design Quality Metrics by Marta Olszewska, please visithttp://tucs.fi/publications/view/?pub_id=tOl11a.  To read the paper, Complexity Analysis of Simulink Models to improve the Quality of Outsourcing in an Automotive Company by J. Prabhu, please visithttp://www.engpaper.com/complexity-analysis-of%C2%A0simulink-models-to-improve-the-quality-of-outsourcing-in-an-automotive-company.htm. 

  We get it. You’re tired of talking about Millennials. But look around your workplace. How is this generation affecting your workplace culture? How have they affected the way you work? What changes has your organization made in the way it hires and operates in order to attract and accommodate millennial talent?  As they slowly, but surely, become a workplace majority, organizations are grappling with the question of how to integrate the different ideas, skills, mannerisms and beliefs that this generation brings to the...

Mayank Prakash - Director General, Digital Technology - DWP Hello. My name is Mayank Prakash and I’m the Director General, Digital Technology at the Department for Work and Pensions. I started at DWP back in November, and so far it’s been a hugely exciting introduction to the world of government technology. I’ve spent a lot of time meeting people and learning, and getting to grips with how it all fits together. DWP is the country’s biggest public service department. It handles pensions and benefits - its work affects the lives of millions of people every day. We’re looking for a Chief Technology Architect. This is the first in a series of new appointments I want to make, the first step towards building a new team of talented people to complement the existing expertise. We believe that technology is integral to business delivery; we’re here to deliver public services to millions of citizens, and we can use technology to make those services better. We want to replace our critical systems with newer digital services we’ve already started to build, using modern technologies such as Node.js, MongoDB and Hadoop. This is big, serious, heavy-duty technical change, an exciting challenge for the right architect. We will be implementing GDS Design Principles, and I’m looking forward to making big changes over the next five years. We’ll be building new platforms and APIs based on open standards and open data. If that sounds like something you want to be part of, find out more about the Chief Technology Architect role in DWP Digital Technology.

C. Aaron Cois Software Engineering Team Lead CERT Cyber Security Solutions DirectorateThis post is the latest in a weekly series to help organizations implement DevOps. On the surface, DevOps sounds great. Automation, collaboration, efficiency—all things you want for your team and organization. But where do you begin? DevOps promises high return on investment in exchange for a significant shift in culture, process, and technology. Substantially changing any one of those things in an established organization can feel like a superhuman feat. So, how can you start your organization on the path to DevOps without compromising your existing business goals and trajectories? This is no easy question, and the answer is different for every organization. The first step is to not focus on automation or new technologies. Instead, look at your current team culture and processes, and identify the biggest sources of risk and inefficiency. A DevOps strategy for your organization should be designed and implemented to address these issues. Implementing a solid DevOps strategy often requires the introduction of new technologies, as with organizations that don't have a standard issue-tracking system in place across all teams or have inconsistent version-control practices.  However, the ultimate goal should be improving communication and process. In many cases the most important solutions are process-based, and may even be informal adjustments to team behaviors. Have Ops (operational) staff been invited to your development project kickoff meetings? If not, isn't that a great opportunity to engender broader support for your project, and get Ops feedback on potential wins or risks for the organization from their perspective? The overarching principle of DevOps is to align the goals of every worker with your ultimate business goal: a fully functional system, running smoothly in production, and delighting customers. Achieving this alignment must be the primary objective shared by all staff, including both Dev (developers) and Ops. Open communication is the first step in aligning goals across your teams. Also, ask questions about goals and incentives: Are your developers held accountable for the success or failure of their code in production? Or, are they actually working toward the internal team goal of handing the packaged code to the Ops team and letting them handle deployment? This bifurcation is a recipe for risk—everyone in the project must be incentivized to make decisions that will ensure both a successful deployment and a reliable system in the field. Often, the biggest cultural win comes from focusing all stakeholders on the ultimate business goal, instead of their isolated team goals, and giving them the space to optimize their processes to achieve this ultimate objective. Every Thursday, the SEI will publish a new blog post that will offer guidelines and practical advice to organizations seeking to adopt DevOps in practice. We welcome your feedback on this series, as well as suggestions for future content. Please leave feedback in the comments section below. Additional Resources To read all the installments in our weekly DevOps series, 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.

Ben Holliday At the start of a project in ‘Discovery’ your team’s job is to learn as much as possible about what your users need to do. Your goal is to understand the user needs for the service before you start to design or prioritise solutions. Jon Kolko describes this process beautifully in his book ‘Well designed: How to use empathy to create products that people love’: "Your job is to help your team ship the right product to your users. Your job is to figure out who your users are, what they want to be able to do, and what the right products are to help them do that. You’ll need to spend time with the people who are going to use your product and watch them do whatever it is they do. Your goal is to both understand them and empathise with them." Understanding user needs is more about having a willingness to learn, than knowing what you’re doing. The important thing in ‘Discovery’ is to go and see things for yourself. Depending on your job role, this might feel uncomfortable or put you in unfamiliar situations. This is all part of the learning opportunity to see things differently. Experiences like this help us to break away from existing assumptions about who our users are and what they need. Try to involve your entire team in this process. If you do have a dedicated user researcher in your team they’ll be able to help you. If not, talk to your User Research team for advice. Start with what happens now You want to know what people need to do, so a good place to start is to find out what they do now. When you’re working on a digital service, it’s rare that this will be solving a completely new problem. Start by looking at existing channels. For some services this might include telephony (phone services), a paper process, or face-to-face interactions with front-line staff. Think about who your service is for. As you start to learn more about what these people need, you’ll begin to understand the details of what they do - where, when, and how frequently. An example - Cold Weather Payments An example project we use in the Digital Academy is Cold Weather Payments. This is where, if you’re getting certain benefits, you may get a Cold Weather Payment of £25 for each 7-day period of very cold weather between 1 November and 31 March. We know that, broadly speaking, the people that benefit from this service are pensioners, and people that get income-related benefits. A good place to start would be to talk to the people in these groups. You could even start with your own friends and family if they get Cold Weather Payments. We also know that we tell people on GOV.UK to contact their local Jobcentre Plus or pension centre if they have questions about Cold Weather Payments, for example, if they think they have a missing payment. We could start by talking to staff about the types of customers that contact them or arrange to listen to calls to understand the support and advice being provided. We could even call existing helplines to ask questions ‘as a customer’ so we can experience what it’s really like to use the service. Any of these approaches should start to show us what happens now. For example, the policy intent for Cold Weather Payments is that people will be able to afford to put their heating on, but what if we found that most people spent the extra money on something else? Maybe people don’t know they’re getting Cold Weather Payments so don’t turn the heating on when the weather is cold because they don’t realise they can afford to. With this type of insight we can start to understand that people have a need to know they’re getting Cold Weather Payments so they know they can afford to put the heating on and use this money for its intended purpose. Make a research plan It’s important to have a plan, but it’s equally important to keep planning to a minimum - don’t use this as an excuse not to get started because time is often limited at the start of projects. Assume that, at least to start with, you’re probably going to ask the wrong questions and have incorrect assumptions about users - this is the whole point of ‘Discovery’. Start by writing a short research plan. Keep this simple, but include:  a summary of what you want to learn (use bullet points for any key questions you need to answer)  a set of opened-ended questions you can use when talking to people (don’t include more than 10 questions - these should help you focus on what you want to learn, acting more as prompts, rather than like ‘survey’ questions). When you talk to people, let the conversation flow rather than sticking rigidly to your plan. The most difficult skill to master is giving people the space to talk without interrupting them (this is harder than you think). As you start to learn you’ll want to make adjustments to your initial set of questions, so don’t be afraid to do this as you go along. Most importantly, make sure that you don’t ask people questions about their preferences - we’re interested in what they do, rather than their opinions. Keep a record of what you learn Find ways to record and keep a record of everything you’re learning. This will help you to share what you find with the rest of your team. If you’re working on your own try to take some notes. If you can work in a pair let someone else take notes while you ask questions. Most importantly, take time out to write down key observations or quotes. It’s a good idea to use post-it notes so you can stick up observations in your project space to discuss with your team. Don’t treat ‘Discovery’ as an exact science At the ‘Discovery’ stage of a project we’re interested in empathy and understanding. It’s not about how much research you do, it’s about how well you understand the needs of your users. This way you’ll be better equipped to make difficult product decisions as you prioritise work to build your service.

By Douglas C. Schmidt Principal Researcher In 2014, the SEI blog has experienced unprecedented growth, with visitors in record numbers learning more about our work in big data, secure coding for Android, malware analysis, Heartbleed, and V Models for Testing. In 2014 (through December 21), the SEI blog logged 129,000 visits, nearly double the entire 2013 yearly total of 66,757 visits. As we look back on the last 12 months, this blog posting highlights our 10 most popular blog posts (based on the number of visits). As we did with our mid-year review, we will include links to additional related resources that readers might find of interest. When possible, we grouped posts by research area to make it easier for readers to learn about related areas of work. This blog post first presents the top 10 posts and then provides a deeper dive into each area of research.  Using V Model for Testing Two Secure Coding Tools for Analyzing Android Apps (secure coding) Common Testing Problems: Pitfalls to Prevent and Navigate Four Principles of Engineering Scalable, Big Data Systems (big data) A New Approach to Prioritizing Malware Analysis Secure Coding for the Android Platform (secure coding) A Generalized Model for Automated DevOps (DevOps) Writing Effective Yara Signatures to Identify Malware  An Introduction to DevOps (DevOps) The Importance of Software Architecture in Big Data Systems (big data) 1. Using V Model for Testing Don Firesmith’s post, Using V Models for Testing, which was published in November 2013, remains the most popular post. In the post, Firesmith introduces three variants on the traditional V model of system or software development that make it more useful to testers, quality engineers, and other stakeholders interested in the use of testing as a verification and validation method. The V model builds on the traditional waterfall model of system or software development by emphasizing verification and validation. The V model takes the bottom half of the waterfall model and bends it upward into the form of a V, so that the activities on the right verify or validate the work products of the activity on the left. More specifically, the left side of the V represents the analysis activities that decompose users’ needs into small, manageable pieces, while the right side of the V shows the corresponding synthesis activities that aggregate (and test) these pieces into a system that meets users’ needs. The single V model modifies the nodes of the traditional V model to represent the executable work products to be tested rather than the activities used to produce them. The double V model adds a second V to show the type of tests corresponding to each of these executable work products. The triple V model adds a third V to illustrate the importance of verifying the tests to determine whether they contain defects that could stop or delay testing or lead to false positive or false negative test results. In the triple-V model, it is not required or even advisable to wait until the right side of the V to perform testing. Unlike the traditional model, where tests may be developed but not executed until the code exists (i.e., the right side of the V), with executable requirements and architecture models, tests can now be executed on the left side of the V. Readers interested in finding out more about Firesmith’s work in this field, can view the following resources: Book: Common System and Software Testing Pitfalls Podcast: Three Variations on the V Model for System and Software Testing 2. Two Secure Coding Tools for Analyzing Android Apps (secure coding)6. Secure Coding for the Android Platform (secure coding) One of the most popular areas of research among SEI blog readers so far this year has been the series of posts highlighting our work on secure coding for the Android platform. Android is an important area to focus on, given its mobile device market dominance (82 percent of worldwide market share in the third quarter of 2013), the adoption of Android by the Department of Defense, and the emergence of popular massive open online courses on Android programming and security. Since its publication in late April, the post Two Secure Coding Tools for Analyzing Android Apps, by Will Klieber and Lori Flynn, has been the second most popular post on our site. The post highlights a tool they developed, DidFail, that addresses a problem often seen in information flow analysis: the leakage of sensitive information from a sensitive source to a restricted sink (taint flow). Previous static analyzers for Android taint flow did not combine precise analysis within components with analysis of communication between Android components (intent flows). CERT’s new tool analyzes taint flow for sets of Android apps, not only single apps.  DidFail is available to the public as a free download. Also available is a small test suite of apps that demonstrates the functionality that DidFail provides. The second tool, which was developed for a limited audience and is not yet publicly available, addresses activity hijacking attacks, which occur when a malicious app receives a message (an intent) that was intended for another app, but not explicitly designated for it. The post by Klieber and Flynn is the latest in a series detailing the CERT Secure Coding team’s work on techniques and tools for analyzing code for mobile computing platforms.  In April, Flynn also wrote a post, Secure Coding for the Android Platform, the sixth most popular post in 2014. In that post, Flynn highlights secure coding rules and guidelines specific to the use of Java in the Android platform. Although the CERT Secure Coding Team has developed secure coding rules and guidelines for Java, prior to 2013 the team had not developed a set of secure coding rules that were specific to Java’s application in the Android platform. Flynn’s post discusses our initial set of Android rules and guidelines, which include mapping our existing Java secure coding rules and guidelines to Android and creating new Android-specific rules for Java secure coding. Readers interested in finding out more about the CERT Secure Coding Team’s work in secure coding for the Android platform can view the following additional resources:  Paper: Android Taint Flow Analysis for App Sets (SOAP 2014 workshop) Presentation: Android Taint Flow Analysis for App Sets Thesis: Precise Static Analysis of Taint Flow for Android Application Sets CERT Secure Coding Rules and Guidelines: CERT Secure Coding Rules and Guidelines for Android wiki 3. Common Testing Problems: Pitfalls to Prevent and Navigate A widely cited study for the National Institute of Standards & Technology (NIST) reports that inadequate testing methods and tools annually cost the U.S. economy between $22.2 billion and $59.5 billion, with roughly half of these costs borne by software developers in the form of extra testing and half by software users in the form of failure avoidance and mitigation efforts. The same study notes that between 25 percent and 90 percent of software development budgets are often spent on testing. In his series on testing, Don Firesmith highlights results of an analysis that documents problems that commonly occur during testing. Specifically, this series of posts identifies and describes 77 testing problems organized into 14 categories; lists potential symptoms by which each can be recognized, potential negative consequences, and potential causes; and makes recommendations for preventing them or mitigating their effects. Here’s an excerpt from the first post, Common Testing Problems: Pitfalls to Prevent and Navigate, which focused on general testing problems that are not specific to any type of testing, but apply to all different types of testing:  Clearly, there are major problems with the efficiency and effectiveness of testing as it is currently performed in practice. In the course of three decades of developing systems and software—as well my involvement in numerous independent technical assessments of development projects—I have identified and analyzed testing-related problems that other engineers, managers, and I have observed to commonly occur during testing. I also solicited feedback from various LinkedIn groups (such as Bug Free: Discussions in Software Testing, Software Testing and Quality Assurance) and the International Council on Systems Engineering (INCOSE). As of March 2013, I have received and incorporated feedback from 29 reviewers in 10 countries. While the resulting framework of problems can apply to both software and systems testing, it emphasizes software because that is where most of the testing problems occur.  Readers interested in finding out more about Firesmith’s research in this area can view the following additional resources:  Presentation: Common Testing Problems: Pitfalls to Prevent and Mitigate, and the associated Checklist Including Symptoms and Recommendations, which were presented at the FAA Verification and Validation Summit 8 (2012) in Atlantic City, New Jersey on 10 October 2012. 4. Four Principles of Engineering Scalable, Big Data Systems (big data)10. The Importance of Software Architecture in Big Data Systems (big data) New data sources, ranging from diverse business transactions to social media, high-resolution sensors, and the Internet of Things, are creating a digital tsunami of big data that must be captured, processed, integrated, analyzed, and archived. Big data systems that store and analyze petabytes of data are becoming increasingly common in many application domains. These systems represent major, long-term investments, requiring considerable financial commitments and massive scale software and system deployments. With analysts estimating data storage growth at 30 percent to 60 percent per year, organizations must develop a long-term strategy to address the challenge of managing projects that analyze exponentially growing data sets with predictable, linear costs.  In his popular, ongoing Big Data series on the SEI blog, researcher Ian Gorton continues to describe the software engineering challenges of big data systems. His most popular post in this series, Four Principles of Engineering Scalable, Big Data Systems, offers four principles that hold for any scalable, big data systems. These principles can help architects continually validate major design decisions across development iterations, and hence provide a guide through the complex collection of design trade-offs all big data systems requires. Here’s an excerpt:  In earlier posts on big data, I have written about how long-held design approaches for software systems simply don’t work as we build larger, scalable big data systems. Examples of design factors that must be addressed for success at scale include the need to handle the ever-present failures that occur at scale, assure the necessary levels of availability and responsiveness, and devise optimizations that drive down costs. Of course, the required application functionality and engineering constraints, such as schedule and budgets, directly impact the manner in which these factors manifest themselves in any specific big data system.  In The Importance of Software Architecture in Big Data Systems, the 10th most popular post in 2014, Gorton continues to address the software engineering challenges of big data, by exploring how the nature of building highly scalable, long-lived big data applications influences iterative and incremental design approaches. Readers interested in finding out more about Gorton’s research in big data can also view the following additional resources: Webinar: Software Architecture for Big Data Systems Podcast: An Approach to Managing the Software Engineering Challenges of Big Data Podcast: Four Principles for Engineering Scalable, Big Data Systems Blog Post: In the blog  post, Addressing the Software Engineering Challenges of Big Data, Gorton describes a risk reduction approach called Lightweight Evaluation and Architecture Prototyping (for Big Data) that he developed with fellow researchers at the SEI. The approach is based on principles drawn from proven architecture and technology analysis and evaluation techniques to help the Department of Defense (DoD) and other enterprises develop and evolve systems to manage big data.  Blog Post: In the blog post, Principles of Big Data Systems: You Can’t Manage What You Don’t Monitor, Gorton takes a deeper dive into one of the four challenges that he enumerated in his post, namely, you can’t manage what you don’t monitor.  5. A New Approach to Prioritizing Malware Analysis  Every day, analysts at major anti-virus companies and research organizations are inundated with new malware samples. From Flame to lesser-known strains, figures indicate that the number of malware samples released each day continues to rise. In 2011, malware authors unleashed approximately 70,000 new strains per day, according to figures reported by Eugene Kaspersky. The following year, McAfee reported that 100,000 new strains of malware were unleashed each day. An article published in the October 2013 issue of IEEE Spectrum, updated that figure to approximately 150,000 new malware strains. Not enough manpower exists to manually address the sheer volume of new malware samples that arrive daily in analysts’ queues.  CERT researcher Jose Morales sought to develop an approach that would allow analysts to identify and focus first on the most destructive binary files. In his April 2014 blog post, A New Approach to Prioritizing Malware Analysis, Morales describes the results of research he conducted with fellow researchers at the SEI and CMU’s Robotics Institute highlighting an analysis that demonstrates the validity (with 98 percent accuracy) of an approach that helps analysts distinguish between the malicious and benign nature of a binary file. This blog post is a follow up to his 2013 post Prioritizing Malware Analysis that describes the approach, which is based on the file’s execution behavior. Readers interested in learning more about prioritizing malware analysis, should listen to the following resource:  Podcast: Characterizing and Prioritizing Malicious Code  7. A Generalized Model for Automated DevOps (DevOps)9. An Introduction to DevOps (DevOps) In June, C. Aaron Cois wrote the blog post A Generalized Model for Automated DevOps where he presents a generalized model for automated DevOps and describes the significant potential advantages for a modern software development team.    With the post An Introduction to DevOps, Cois kicked off a series exploring various facets of DevOps from an internal perspective and his own experiences as a software engineering team lead.  Here’s an excerpt from his initial post:  At Flickr, the video- and photo-sharing website, the live software platform is updated at least 10 times a day. Flickr accomplishes this through an automated testing cycle that includes comprehensive unit testing and integration testing at all levels of the software stack in a realistic staging environment. If the code passes, it is then tagged, released, built, and pushed into production. This type of lean organization, where software is delivered on a continuous basis, is exactly what the agile founders envisioned when crafting their manifesto: a nimble, stream-lined process for developing and deploying software into the hands of users while continuously integrating feedback and new requirements. A key to Flickr’s prolific deployment is DevOps, a software development concept that literally and figuratively blends development and operations staff and tools in response to the increasing need for interoperability. The following resources are available to readers interested in learning more about DevOps:  A New Blog Post Series: In November, Cois and other researchers in his group launched a new blogpost series that offers guidelines and practical advice to organizations seeking to adopt DevOps. A new post is published every Thursday.  Podcast: DevOps—Transform Development and Operations for Fast, Secure Deployments  8. Writing Effective Yara Signatures to Identify Malware  In previous blog posts, David French has written about applying similarity measures to malicious code to identify related files and reduce analysis expense. Another way to observe similarity in malicious code is to leverage analyst insights by identifying files that possess some property in common with a particular file of interest. One way to do this is by using YARA, an open-source project that helps researchers identify and classify malware. YARA has gained enormous popularity in recent years as a way for malware researchers and network defenders to communicate their knowledge about malicious files, from identifiers for specific families to signatures capturing common tools, techniques, and procedures (TTPs). In this latest post, Writing Effective Yara Signatures to Identify Malware, which continues to draw a robust audience since its publication in 2012, he provides guidelines for using YARA effectively, focusing on selection of objective criteria derived from malware, the type of criteria most useful in identifying related malware (including strings, resources, and functions), and guidelines for creating YARA signatures using these criteria. Here’s an excerpt:  Reverse engineering is arguably the most expensive form of analysis to apply to malicious files. It is also the process by which the greatest insights can be made against a particular malicious file. Since analysis time is so expensive, however, we constantly seek ways to reduce this cost or to leverage the benefits beyond the initially analyzed file. When classifying and identifying malware, therefore, it is useful to group related files together to cut down on analysis time and leverage analysis of one file against many files. To express such relationships between files, we use the concept of a "malware family", which is loosely defined as "a set of files related by objective criteria derived from the files themselves." Using this definition, we can apply different criteria to different sets of files to form a family. The following resource is available to readers interested in learning more about this work:  Research Report: Function Hashing for Malicious Code Analysis, CERT Research Report, pp 26-29 Wrapping Up 2014 and Looking Ahead  This has been a great year for the SEI Blog. We plan to take a break in publication for the remainder of 2014, but we will kick off 2015 with a series of great posts:  We will kick off a series of posts highlighting the SEI’s technical strategy for 2015 and beyond.  Will Klieber and Lori Flynn will update their continuing research on secure coding for the Android platform.  Sagar Chaki and James Edmondson will detail their research on software model checking for verifying distributed algorithms.  Aaron Cois will continue his series on DevOps with posts on secure and continuous integration.  As always, we welcome your ideas for future posts and your feedback on those already published. Please leave feedback in the comments section below.  Additional Resources Download the latest publications from SEI researchers at our digital library http://resources.sei.cmu.edu/library/. 

Employees spend more than one third of their day at work - for some it can be as much as two-thirds. That's at least one meal a day-- and the vast majority of their waking hours. Given all of the time we spend at work, employers and employees coming together to create a healthy work environment benefits everyone. There is also a business case for workplace wellness. Nearly 1 in 5 Americans have a diagnosable mental health condition each year and many others are at risk. In fact, nearly half of all Americans will...

Nic Harrison - Director of Enabling Digital Delivery I’m Nic Harrison, the Director of Enabling Digital Delivery, part of DWP’s Business Transformation Group. I’ve been with the department for a year, working with Kevin Cunnington to put in place the organisation and plans needed to deliver a once in a lifetime transformation for our citizens, third party partners and staff. I used to live in Dallas, Texas where there is a good ‘ole boy saying: "fixin’ to get ready". This means doing all the necessary preparation before a big task can start. I really feel 2014 was about "fixin’ to get ready" for the huge year we have in front of us in 2015. Last year we put in place Digital Academies to train our staff, we recruited a number of specialists to provide leadership and guidance in new technology and techniques (take a bow Ben Holliday, my colleague and Head of User Experience) and we worked with the change programmes to ensure consistency and promote re-use across the department. In short, we put in place the foundations on which to build the new DWP. The enabling part of Enabling Digital Delivery is about making sure we have robust designs that deliver great, user centred services. This is often more about the parts of a service that cannot be delivered with technology than the parts that can be. Really good design puts human intervention where it is needed and valuable and it automates whenever we can do that safely and securely. That’s why we look at user journeys and test and learn around real user experiences. However when we can automate, we need first class 21C technology to support us. That’s why I am delighted we have our new Director General for Technology, Mayank Prakash,  in the department. We are already drawing on expertise from the Chief Technology Office domain architecture function in order to understand the "art of the possible" from our current and future IT estate. I am sure that Mayank’s vision for the department’s technology will bring new and exciting opportunities to leverage technology and deliver innovative services. After "fixin to get ready" last year, we are now really getting going with the momentous task of transforming DWP together.

By John HallerSenior Member of the Technical Staff CERT Division Attacks and disruptions to complex supply chains for information and communications technology (ICT) and services are increasingly gaining attention. Recent incidents, such as the Target breach, the HAVEX series of attacks on the energy infrastructure, and the recently disclosed series of intrusions affecting DoD TRANSCOM contractors, highlight supply chain risk management as a cross-cutting cybersecurity problem. This risk management problem goes by different names, for example, Supply Chain Risk Management (SCRM) or Risk Management for Third Party Relationships. The common challenge, however, is having confidence in the security practices and processes of entities on which an organization relies, when the relationship with those entities may be, at best, an arms-length agreement. This blog post highlights supply chain risks faced by the Department of Defense (DoD), federal civilian agencies, and industry; argues that these problems are more alike than different across these sectors; and introduces practices to help organizations better manage these risks.   Protecting Key Assets In the past, when government or business invested in a piece of machinery, appliance, or service, it could more or less expect the item to function as advertised. Checks and balances (such as licenses, warranties, regulations, legal recourse, and supplier reputation) reasonably ensured against defects or service failures. Unfortunately, such controls seem increasingly inadequate when applied to global supply chains for the complex information and communications technology—and technology-based services—that underpin critical capabilities in most organizations, especially in mission- and safety-critical operations in the US government and DoD. Concerns about supply chain risk management in ICT include the possibility that counterfeit or maliciously tainted hardware and software might be used by an acquiring organization to its detriment. Also, organizations often face uncertain risks because of their dependence on external entities for the ongoing use and sustainment of ICT—the so-called service supply chain (Please see Supply Chain Risk Management Practices for Federal Systems and Organizations from the National Institute of Standards & Technology NIST 800-161 section 1.4, page 3 for a discussion and definition of ICT services as part of the SCRM). Supply chain risk concerns can often seem "special" or specific to a particular industry or sector. For example, healthcare institutions must ensure that business associates with whom they share private health information will protect that information. Similarly, the defense sector has concerns about verifying the trustworthiness of subcontractors with which they may share sensitive weapons system information. In each case, however, the essential problem is the same. The organization has key assets—financial account information, private health information, or defense systems information— that must be protected for the organization to be successful. When the organization relies on a supply chain, it is forced to depend on processes, capabilities, and actions outside its direct control for that protection. External dependencies can range from contracts with cloud-service providers for data storage, to reliance on public infrastructure. As part of its work on critical infrastructure cybersecurity, researchers in the SEI’s CERT Division seek to help organizations by providing common ways to assess and improve external dependency management across the entire lifecycle of external entity relationships. The lifecycle includes selecting suppliers and vendors and conducting initial risk assessments, managing ongoing relationships, and planning and conducting the incident response activities needed if the organization experiences a disruption involving the external entity. Different critical infrastructure and government sectors refer to the risk of depending on external entities to support key services by different names. The DoD frequently uses the term supply chain risk management to refer to concerns about the integrity of hardware and software, while the financial community is facing increasing scrutiny over "third-party risk." CERT researchers advocate "external dependency management" as a broad term for management activities to control the risks of these relationships. The Realities of Managing Suppliers and Dependency Risk Managing dependence on external entities is challenging because it is hard to verify the trustworthiness of suppliers’ security practices and processes across arm’s-length relationships. Typically, the most basic step taken to control risk involves the codification of security requirements into contracts and other formal agreements. However, contracts can be of limited use because of uncertainty around contractual duties, the difficulty of proving breach involving complex ICT systems, or the rate of technological change.  Organizations may also simply not have an ability to really negotiate security requirements, or it may be unrealistic to expect a particular vendor to meet a very high level of cybersecurity. Other approaches often used to mitigate this problem are simply ineffective in certain threat environments. For example, asking a vendor to complete a checklist is often unsatisfactory because either this activity does not capture the context of the particular relationship, or it only captures the state of affairs at one point in time. By contrast, building a strong relationship from the earliest stages of the supplier lifecycle can help to build communication essential to managing dependency risk. Trust can be built over time to improve communications, recognizing that suppliers’ business and resource constraints drive their actions. A sometimes overlooked—but very basic—challenge involves gathering information and establishing trusted communication with suppliers. Financial services companies, for example, are often connected to a wide array of suppliers needed for payments, clearing and settlement, data processing, communications and so on. The resource demands of managing multiple suppliers across organizational boundaries can be daunting. Organizations should start by having a good process to identify and prioritize the critical few external entities. Having identified and prioritized dependencies, the next section of this post will explore the development of requirements for those entities. Building External Dependencies Management Practices Establishing requirements for external entities (See also, Office of the Comptroller of the Currency Guidance on Risk Management Lifecycle.) is a foundational, essential aspect of managing dependency risk.  Requirements are largely driven by the need to protect and sustain assets used to support high-value services. Requirements may also support regulations or corporate policy. For example, HIPAA requires the protection of health information, a requirement that specifically extends to business associates as defined under the law.  The criticality of the service and the importance of the supplier to that service drive the requirement, for example protecting information or ensuring continuous availability. Requirements provide the basis for prioritizing and managing external entity relationships.   Of course, well-defined requirements will not change the degree to which the organization can control suppliers or drive their behavior.  When organizations have little meaningful control over third parties, they must employ practices and strategies that can be controlled internally. Management practices may be characterized into three categories: internal practices that can be executed and directly controlled by an organization, such as using multiple vendors, limiting the type of information external suppliers are allowed to process, or accounting for the external dependency as part of response planning  external practices that the organization requires the supplier to perform such as encrypting data, monitoring network access, or testing of business continuity plans cooperative activities that organizations can do in collaboration with suppliers such as conducting joint assessments of controls or the sharing cyber-threat data Wrapping Up and Looking Ahead In the face of increasingly sophisticated and frequent cybersecurity attacks, organizations can use a mix of internal, external and cooperative controls to help manage risks and meet requirements. Often, as trust evolves with suppliers over time, it is possible to refine the mix of supplier management strategies and build collaborative approaches to managing risks.  In the case of public and shared suppliers, the use of cooperative risk management strategies can be one of the most effective means of managing risk. The DoD-Defense Industrial Base Collaborative Information Sharing Environment (DCISE) is one example of how this is currently being done, as is the Department of Homeland Security's National Cybersecurity Communications and Integration Center. It has become increasingly evident that increased collaboration including the sharing of information is needed to help organizations protect critical resources. For many organizations, relationships with partners and other outside entities are the predominant way they learn about incidents, rather than internal technical monitoring (See page 53 of the 2013 Verizon Data Investigation’s Report). External dependency management is more similar than different across the public and private organizations that underpin Americans’ security and economy. Organizations need opportunities to improve their capability and learn from one another. For these reasons, CERT is sponsoring a Supply Chain Risk Management Symposium on January 15, 2015 in Arlington, Va. Additional Resources For more information or to register for the CERT Suply chain Risk Management Symposium, please visithttp://www.cert.org/scrm. To view the webinar Lessons in External Dependency and Supply Chain Risk Management featuring CERT researchers John Haller and Matthew Butkovic, please visithttps://www.webcaster4.com/Webcast/Page/139/5934.