Ben Holliday - Head of User Experience Design In my previous Digital Academy blog post, I wrote about how to get started with discovery research. Ideally your team will have been part of this process, getting involved with research and taking part in analysis sessions. For people like product managers or key stakeholders this won’t always happen. In agile teams time is limited. The reality is people won’t have the time to read research reports and they won’t always have the same shared understanding of problems when it comes to planning and prioritisation. Teams need ways of getting hold of the actionable learnings from research. The key to this is ‘insights’. Introducing insights Insights are short statements that give us enough shared understanding to take an action. For example, this is an insight from our State Pension research: "People confuse their current State Pension with the amount they’ll get when they retire" The best ideas, innovations, or product iterations can come from a single insight like this. It’s worth considering that insights will often be the result of frustrations­ seeing people struggle with a product. What makes a good insight Insights should feel simple because they are simple. They should also be provocative - this is what makes them actionable. They should challenge how we think about problems we’re trying to solve - helping us to find new and improved ways of meeting user needs. The best insights are like problem statements. We want our teams to use their experience and skills to solve the design challenges they create. Insights should make space for this to happen. This is where the big and interesting ideas are. Designers will naturally make intuitive leaps. They’ll be able to develop ideas that move a team towards building something that works better for users - solutions that respond to individual insights. User research won’t tell you what to do. You need to work towards solutions using what you’re learning as a guide. Insights aren’t an exact science It’s important to remember that we’re looking for insights, not proof. Design research isn’t scientific. We still need to use our own interpretations of data to get to something that’s actionable. It’s therefore okay if insights turn out to be wrong. We only learn how true our insight statements are by doing more research. Even when we’re not right we’re still making informed design decisions. This is also how we deal with sample size and confidence in our research. Insights are not a full representation of all customers but they help us make design decisions that can benefit everyone. When working with large data sets teams can suffer from analysis paralysis. Problems can be hard to see in complex data. Insights can help cut through and give focus to a team. How to get to insights The data from user research will always be messy and needs analysis. It’s hard to get to good insights so research analysis is very important. A good approach is to affinity sort observations from your research into common themes. See Natalie’s blog post about capturing user feedback to get started. Insights should be written down as part of this research analysis. You’re looking to get to a clear actionable insight for each theme or group of observations. Some insight examples "People don’t know that they can turn on their heating when the weather is cold" This is an example from our Digital Academy project Cold Weather Payments. It’s a good insight that helps us set a design challenge - ­ "how can we let people know they’ve received a cold weather payment?". "People on low incomes don’t know whether they’re employed or self-employed" This example is from our live Carer's Allowance digital service. Again, it’s a good insight. It’s okay that it’s framed as a statement of fact ­- this makes it provocative and actionable. The reality is some people understood if they were self-employed but stating this as a truth makes it easier to set a design challenge that might benefit everyone. For example "how can we capture employment information without people having to self-­determine if they’re employed or self-employed?" Note -­ neither of these examples suggest a solution. Making insights part of your workflow Look for patterns in the insights you find as you iterate a product through different rounds of user research. Eventually you should find that insights are an important part of your workflow. Your team will rely on them in their decision making and planning sessions. They can also be a useful focal point for show & tell sessions with your team and wider stakeholders ­- a great way to communicate what you’re learning.

Because the Faragher affirmative defense to illegal harassment grew out of the seeds we planted in my amicus brief for SHRM in the United States Supreme Court, I treat harassment policies and their complaint procedures with extra tender love and care.  If the Human Resource Professional is going to be the gardener who prevents internal harassment complaints from growing into lawsuit weeds, every word in the policy must be chosen with the knowledge that it will be placed under a microscope by your employees, your employees’ attorneys, and possibly the EEOC or the NLRB.  Let’s start...

The current Parliament ended on 30 March. Between then and the general election on 7 May is the pre-election period and the Civil Service communicates less, in line with the General Election Guidance. In the 5 weeks up to the election, we’ll only use this blog to provide information essential to continuing the government’s day-to-day work. This applies to @DigitalDWP too.

By Mike Gagliardi, Principal Engineer Software Solutions DivisionIn Department of Defense (DoD) programs, cooperation among software and system components is critical. A system of systems (SoS) is used to accomplish a number of missions where cooperation among individual systems is critical to providing (new) capabilities that the systems could not provide. SoS capabilities are a major driver in the architecture of the SoS and selection of constituent systems for the SoS. There are additional critical drivers, however, that must be accounted for in the architecture that significantly impact the behavior of the SoS capabilities, as well as the development and sustainment of the SoS and its constituent systems’ architectures. These additional drivers are the quality attributes, such as performance, availability, scalability, security, usability, testability, safety, training, reusability, interoperability, and maintainability. This blog post, the first in a series, introduces the Mission Thread Workshop (MTW), and describes the role that it plays in assisting SoS programs to elicit and refine end-to-end SoS mission threads augmented with quality attribute considerations. A mission thread is a sequence of end-to-end activities and events presented as a series of steps that accomplish the execution of one or more capabilities that the SoS supports. Simply listing the steps and describing them, however, does not reveal all the important concerns associated with cooperation among the systems to accomplish the mission and their ensuing behaviors. Articulating and understanding the architectural considerations associated with the mission threads are therefore critical to identifying any architecture mismatches between systems and the SoS. Mission threads must be augmented with quality attribute considerations. An MTW uses existing SoS end-to-end mission threads and accompanying architecture plans and augments the mission threads with quality attribute, engineering, and capability considerations with inputs from stakeholders. The MTW identifies architecturally significant SoS challenges that are distilled from the architecture, engineering, and capability issues identified in the post-MTW analysis of the quality attribute augmented mission threads. The MTW also identifies candidate legacy systems that have potential architectural mismatches with the SoS and provides the architecture context from which to perform post-MTW architecture evaluations of the candidate legacy system and software architectures. A mission thread takes place in the context defined by a vignette. The purpose of a vignette is to describe those environmental factors that may be architecturally significant—that is, they impose a constraint on the architecture that would not exist in the absence of these environmental factors. This story can usually be told in a paragraph or two, with an accompanying context diagram showing the nodes containing the systems. The quality attribute augmented mission threads and SoS challenges serve as important inputs to architecture development, architecture evaluation, and constituent system and software architecture evaluations. The MTW is based on the principles of the Software Engineering Institute’s software architecture methods and practices, extended and scaled into the SoS domain. These principles include eliciting stakeholder inputs early in the life cycle articulating and addressing the quality attributes that drive the architecture early in the life cycle identifying challenges impacting architectural decisions early in the life cycle Un-augmented mission threads and vignettes are critical inputs to the MTW and are developed during the preparation phase. A vignette is a short story about the environment that provides the context in which the SoS exists. Mission threads and vignettes are developed by the SoS program’s architect(s) with assistance from the MTW team and are typically based on existing mission threads/vignettes for the SoS and updated for use in the MTW. Sometimes mission threads or vignettes must be developed from scratch if no relevant ones exist. Mission Threads and Operational Vignettes Through our work on a number of SoS and commercial enterprise architectures within the DoD, we have identified three basic types of mission threads: An operational mission thread describes how SoS nodes (and perhaps the systems within the nodes) react to an operational stimulus. The operational mission thread is presented as an end-to-end sequence of steps (external events, operator activities, and automated activities) that take place over a time period. For example, an operational mission thread for a DoD command-and-control system might begin with threat detection followed by a number of steps to determine the intent of the threat, make decisions to counter the threat, apply the counter measures, and finally document the commander’s assessment of damage after completion. A development mission thread focuses on development activities including adding new capabilities, technology refreshment, integration, test, certification, and release. A sustainment mission thread focuses on deployment, installation, sustainment, or maintenance. A sustainment mission thread describes how the SoS nodes operate together to sustain the SoS. Examples The following examples present an operational vignette for ballistic missile defense in a naval context: Two ships (Alpha and Beta) are assigned to air defense to protect a fleet containing two high-value assets. A surveillance aircraft and four unmanned aerial vehicles (UAVs; two pairs) are assigned to the fleet and controlled by the ships. A pair of UAVs flying as a constellation can provide fire-control quality tracks directly to the two ships. A two-pronged attack on the fleet occurs: five aircraft-launched missiles from the southeast three minutes later, seven submarine-launched missiles from the southwest The fleet is protected with no battle damage. An example mission thread (un-augmented) supporting the Ballistic Missile Defense vignette is provided in the following table; it serves as an input to the MTW, and will be augmented with quality attribute, engineering, and capability considerations during the MTW. Conceptual Flow The figure below depicts the conceptual flow of the MTW. SoS drivers and capabilities inform the development of vignettes and mission threads from which a set of quality attributes are derived. Plans for SoS architecture development include an initial set of architecture views that support the vignettes and mission threads. Constituent legacy systems are identified for consideration in the SoS architecture, based on the capabilities and mission threads. The MTW team uses these inputs to augment the mission threads with quality attribute considerations, as well as engineering and capability considerations, with participation from SoS and legacy system stakeholders. The other outputs from the MTW are the SoS challenges derived from the issues identified in the qualitative analysis. The augmented mission threads and challenges will drive important architectural decisions during architecture development. Concluding Remarks Many quality attributes in SoS programs require architectural support at various levels, accompanied by analyses of the various architectural approaches and their trade-offs. Failure to address quality attributes in the architectures can lead to serious consequences, such as operational and developmental failures; addressing these late in the development life cycle increases risks to programs. These risks are exacerbated in SoS architectures comprising legacy system and software architectures. After performing more than 30 MTWs in the context of SoS programs, SEI researchers have observed several trends: First, buy-in from the principals and the stakeholders is critical to the success of the approach, as in all stakeholder-focused methods. To encourage buy-in, the SEI’s MTW teams often developed an initial thread in the stakeholders’ domains for review. Strong third-party facilitation has been critical to the success of the MTW approach. Challenges identified by consensus under independent third-party facilitation tend to benefit from higher group buy-in than do challenges identified by various factions among SoS stakeholders. We also discovered that the architectural challenges identified in MTWs often result in updates to the SoS CONOPS and mission needs statements. Although third-party facilitation is important, motivated programs can adopt the MTW process for their own use. For example, after participating in a few MTWs facilitated by the SEI, a DoD Naval program was able to successfully execute its own MTWs. SoS architecture principles and guidelines were often absent when we began an engagement. Documenting the principles and guidelines for the SoS architecture is beneficial to drive and constrain the architecture development process for both SoS and constituent systems, including legacy modifications. We found that the MTW approach feeds the development of these principles and guidelines. With proper scoping and selection of vignettes and mission threads, programs easily can attain a high percentage of coverage of their SoS’s envisioned capability, which can provide a focused starting point for the architecture development effort. Overall, our experience in executing a number of MTWs for a variety of clients has been very positive. The clients all gained insight into the desired behavior of their SoS and constituent systems; identified architectural challenges, engineering challenges, and capability gaps; and defined architecture guidelines and principles to guide their development. These outcomes help a program avoid the costly consequences of development and operational failures and lead to more cost-effective and on-time delivery of new capabilities for the SoS. This blog post is the first in a series on the MTW. Future posts will explore the steps of the MTW in detail and provide examples, experiences, and lessons learned in its application. Additional Resources To read the SEI technical report, Introduction to the Mission Thread Workshop, please visit, http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=63148. To view the presentation, Identifying Architectural Challenges in System of Systems Architectures, please visithttp://www.acq.osd.mil/se/webinars/2014_07_15-SoSECIE-Gagliardi-brief.pdf. To view the SATURN presentation, Mission Thread Workshop: Lessons Learned, please visithttp://resources.sei.cmu.edu/library/asset-view.cfm?assetid=19898. To view the SATURN presentation, Mission Thread Workshops: Lessons Learned in End-to-End Capability and Quality Attribute Specification for SoS Architecture Development, please visit http://resources.sei.cmu.edu/library/asset-view.cfm?assetid=19890.

On the Carer's Allowance Digital Service we've had two business Subject Matter Experts (SME) for the past 12 months, they have been Kathryn Baxendale and myself. Kathryn has been on the service since the very start of discovery working with Government Digital Service, she knows the service and business inside and out. I have been on the service for the past 12 months coming on board to support the introduction of CASA and helping pass the service standard assessment. We have both been working in the Carer’s Allowance Unit for over 9 years, we are the voice in the room for the Carer's Allowance Unit and are empowered to make decisions on behalf of the business. Basically we support the end to end development of a user story throughout it’s journey until it is released into live. It's critical when you are building a service that if it’s replacing or improving an already existing service to understand what's currently out there; how this works and how staff feel this could be improved. Staff speak to users every day, they understand the benefit and the current service better than anyone and they have fantastic ideas to make things better for customers which in turn will makes things better in their own jobs.  Some of what an SME does  Representing the business on all user stories ensuring the business is ready to support these critically needed changes. As the business voice in the room we support the Product Owner and the rest of the team with the prioritisation of user stories. Some stories will achieve business benefits as well as improving the journey for users. It’s key that these are also prioritised alongside other stories and this is where the knowledge of the business also comes in.    We sense check content changes before seeking approval from policy teams, we keep in regular contact with policy to keep them informed on current and future changes. We undertake field assurance testing prior to any release and write guidance and communications for each fortnightly release helping staff understand the latest changes to the service and how these changes will affect their day to day jobs and the user journey. We have iterated our guidance to make sure that it quickly and clearly communicates these changes, we have also worked on making guidance very visible. Crucially we are part of user research where we help Researchers and Content Designers understand some of the complexities of the benefit so they can build workable solutions to problems faced by users. As well as being observers, insight note takers and being part of the evaluations, we support research in any way we can such as playing the role of a web chat agent. User research is a team sport and we are part of that team. Co-location co-location co-location It's been vitally important that we are co-located with the team working with them everyday, this is not something that can be done part time. We have understood the proposed changes and readied the business for them, answering questions from User Researchers, Content Designers, Business Analysts, Developers and Product Owners so they can make informed decisions. We are a part of the constant and continuous conversations. And finally If you haven't currently got a business SME and you are looking to replace, or improve an existing service then I would recommend getting one (or two if you're lucky). 

By Chris Taschner Project Lead CERT Cyber Security Solutions Directive This post is the latest installment in a series aimed at helping organizations adopt DevOps. "Software security" often evokes negative feelings among software developers since this term is associated with additional programming effort and uncertainty. To secure software, developers must follow a lot of guidelines that, while intended to satisfy some regulation or other, can be very restricting and hard to understand. As a result a lot of fear, uncertainty, and doubt can surround software security. This blog posting describes how the Rugged Software movement attempts to combat the toxic environment surrounding software security by shifting the paradigm from following rules and guidelines to creatively determining solutions for tough security problems. Rugged software moves from prescriptive restrictions to a set of DevOps principles. Emphasizing a set of DevOps principles enables developers to learn more about what they are developing and how it can be exploited. Rather than just blindly following the required security measures, developers can understand how to think about making their applications rugged. As a result, they can derive their own creative ways to solve security problems. As part of understanding the challenges associated with secure software development, rugged software developers look more at how their software responds in all kinds of situations. Rather than reacting to new attacks, rugged software should be proactively focused on surviving by providing reliable software with a reduced attack surface that is quick both to deploy and restore. In other words, developers worry less about being hacked and more about preventing predictable attacks and quickly recovering from being hacked. In the past, software security focused on anticipating where and how the attacks would come and putting up barriers to prevent those attacks. However, most attacks—especially sophisticated attacks—can’t be anticipated, which means that fixes are bolted on as new attacks are discovered. The inability to anticipate attacks is why we often see patches coming out in response to new 0-day vulnerabilities. Rugged software developers would rather their software absorb the attacks and continue to function. In other words, it should bend but not break. This shift in thinking from a prevent to a bend-don't-break mindset allows for a lot more flexibility when it comes to dealing with attacks. In a rugged world, things can be dropped because they will survive the fall and bounce right back up. Becoming rugged requires the development team to focus on continuous integration, infrastructure as code, eliminating denial of service (DOS), and limiting the attack surface. Continuous Integration Building software should be automated and repeatable. These attributes can best be achieved through continuous integration, or continually merging source code updates from all developers on the development team. When a software development team is able to reliably, quickly, and easily integrate their code, they will be able to focus on creating robust, rugged code rather than having to worry about integration. In addition, they will be able to rule out integration issues when debugging, decreasing the time and effort required to find and fix bugs. Quickly deploying a fix means quickly patching holes and quickly improving security. Infrastructure as Code Software tests and infrastructure should be easy to validate and not left to the whim of whoever is setting up the infrastructure or performing testing. The whole team should be able to review exactly what is going on when the infrastructure is being set up and the code is being tested. Infrastructure (and testing) as code is an example of a means to make infrastructure easy to validate. Eliminating Denial of Service (DOS) The fact that DOS attacks are often easy to launch and can be expensive to defend against makes their elimination a tricky thing. Quite a few people have talked about eliminating DOS. Symantec has an article, and Rugged Software has a Rugged Implementation Guide. Even though DOS attacks been around for quite a while, they are not abating. Moreover, they still manage to do considerable damage, which means it is important to have a solution to this problem. Limiting the Attack Surface Finally, it is very important to limit the attack surface (i.e., the amount of your application that is exposed to nefarious individuals attempting to exploit weaknesses) of your application. Limiting the amount of your application that is accessible to possible attackers limits the number of attacks that your application will encounter. For more information on how to go about limiting your application's exposure, see SANS and the InfoSec Institute. Concentration on exposing as little of the application to the outside world as possible allows the developer to focus security testing on a smaller piece of the application. Doing this at an early stage in an application’s development means that the exposed part has a greater chance to undergo more testing and become more resilient. Continuous integration, infrastructure as code, eliminating DOS, and limiting attack surfaces while developing a software product will all help to make your product rugged. While this doesn't mean that this product is immune from security problems, it does give it a leg up on other products that aren't rugged due to the added resiliency that these techniques provide. Your product will be more likely to survive and thrive in a dangerous world. Every two weeks, the SEI will publish a new blog post offering guidelines and practical advice for organizations seeking to adopt DevOps in practice. We welcome your feedback on this series, as well as suggestions for future content. Please leave feedback in the comments section below. Additional Resources On April 9 at 1:30 p.m. ET, Aaron Volkmann and Todd Waits will present the webinar Culture Shock: Unlocking DevOps with Collaboration and Communication. To register for the webinar, please click here. To listen to the podcast, DevOps—Transform Development and Operations for Fast, Secure Deployments featuring Gene Kim and Julia Allen, please visit http://url.sei.cmu.edu/js. To read all of the blog posts in our DevOps series, please click here.

On May 27, @shrmnextchat chatted with employment attorney Jonathan Segal @jonathan_HR_law about How Workplace Violence Creates HR Nightmares. If you missed this important chat, you can read all the tweets here:   [View the story "#Nextchat RECAP: How Workplace Violence Creates HR Nightmares " on Storify]      ...

This week Digital DWP is sponsoring Leeds GovJam 2015. GovJam is a global event. It’s for anyone and everyone with an interest in public services and making them better. We think this event is a good fit for us. I love the idea of hack events like GovJam. They let everyone join in. They teach people that anyone can be a designer. Not only do they encourage close collaboration, they challenge people to get out the building and to get involved. Digital Academy The thing I’ve been most impressed with since joining the Department for Work and Pensions is the Digital Academy. More than 200 of our staff have now graduated from the Academy. They’re learning about user-centred design, Agile delivery, and most importantly they’re joining in. When people graduate from the Academy they get to learn by doing. They work on real products and services. This isn’t always about individual job roles or skills. It’s about working together to understand a problem and deliver better services. Business transformation In DWP, we’re all now part of this business transformation. To make this happen we need to encourage more people in our organisation to put users first. I believe that anyone already thinking about user-centred design needs to be encouraged. We need to get hold of this potential. It’s not something you can manage, but you can give people the freedom and room to grow. Digital delivery is more than a numbers game. We need to invest in everyone who has the potential to think differently. Anyone who’s willing try and put users first. To go see a problem for themselves and to work hard to make things work better. The cost of learning It defeats the opportunity of the Academy to put blockers in the way of people continuing to learn and grow without doing real work. We will make mistakes and we’ll sometimes lack the experience we need. But learning by doing means that this is okay. As I wrote last week, we’re all a little bit scared of getting out of the building and talking to end-users of our services. We need to be brave. Time and resources will get stretched. Finding experienced people to mentor and support people is difficult. But as Tom Loosemoore from the Government Digital Service told us last year at our DWP Sprint event: "Transformation. It’s not complicated. It’s just hard.". What’s not complicated is we start by putting users first. What happens next Not only am I looking forward to seeing what happens this week at GovJam, more so I’m excited to see just where we will be in 12 months’ time.

By Greg Shannon Chief Scientist CERT Division In 2014, approximately 1 billion records of personably identifiable information were compromised as a result of cybersecurity vulnerabilities. In the face of this onslaught of compromises, it is important to examine fundamental insecurities that CERT researchers have identified and that readers of the CERT/CC blog have found compelling. This post, the first in a series highlighting CERT resources available to the public including blogs and vulnerability notes, focuses on the CERT/CC blog.  This blog post highlights security vulnerability and network security resources to help organizations in government and industry protect against breaches that compromise data. The most visited posts on the CERT/CC blog center around a critical area of research: SSL Certificates as a core foundation of trust transmissions on the Internet along with certificates. These posts explore weaknesses in those trust relationships as implemented in mobile platforms and also highlight tools that have been created at CERT to explore those vulnerabilities. Before we take a deeper dive into SSL Certificates, let's take a look at the top 10 posts (as measured by number of visits) on the CERT blogs: SSL Tools The three most popular posts on the CERT blogs were written by CERT researcher Will Dormann and stemmed from his analysis of network traffic man-in-the-middle (MITM) techniques (HTTP and HTTPS) by using MITM tools/techniques. While there are plenty of MITM proxies, such as ZAP, Burp, Fiddler, mitmproxy, and others, Dormann wanted a transparent network-layer proxy, rather than an application-layer one. After a bit of trial-and-error investigation, he found a software combination that works well for this purpose, CERT Tapioca. Dormann wrote The Risks of SSL Inspection, the most popular post on the CERT blogs, after he started examining the SuperFish and PrivDog vulnerabilities and realized that the SSL inspection techniques used by those two applications are similar to trusted enterprise software that performs SSL inspection. When he started looking into SSL inspection software in general, he realized that many of them are making mistakes that put clients at risk. Here is an excerpt: Recently, SuperFish and PrivDog have received some attention because of the risks that they both introduced to customers because of implementation flaws. Looking closer into these types of applications with my trusty CERT Tapioca VM at hand, I’ve come to realize a few things.In this blog post, I will explain The capabilities of SSL and TLS are not well understood by many. SSL inspection is much more widespread than I suspected. Many applications that perform SSL inspection have flaws that put users at increased risk. Even if SSL inspection were performed at least as well as the browsers do, the risk introduced to users is not zero. The complete post, The Risks of SSL Inspection, can be read here. The CERT/CC post that Dormann wrote that introduced CERT Tapioca, is the second most visited post on the CERT/CC blog in the last six months. In that post, Dormann introduces CERT and takes readers through a test run using the tool. Here is an excerpt: Once you start performing MITM testing of HTTPS traffic, you hopefully will have a better idea of the level of trust that you should be giving HTTPS. Let’s consider the situation where you type https:// and the domain name in your web browser’s address bar for the site that you want to visit. If you don’t get a certificate warning, what does that mean? It really just means that the certificate provided by the server was issued by any one of the root CAs trusted by your browser. For example, the current version of Mozilla Firefox comes pre-loaded with over 90 trusted root CAs. Any one of these sites may provide a dozen or more individual trusted root CA certificates. If you are using a system that you don’t manage, and you’re relying on HTTPS to keep your web traffic from prying eyes, you may want to think twice. Just like we can silently intercept HTTPS traffic by having the mitmproxy root CA certificate installed, you must assume that enterprises with managed desktop systems are employing similar techniques to monitor traffic. It is their network, after all. But it is also worth noting the impact the compromise of a single root CA can have. It’s happened in the past with DigiNotar and Comodo. Without getting too sidetracked here, Moxie Marlinspike’s blog entry SSL And The Future Of Authenticity goes into a good amount of detail about the problems with SSL and trust. The complete post, Announcing CERT Tapioca for MITM Analysis, can be read here. In Finding Android SSL Vulnerabilities with CERT Tapioca, a follow-up to the post introducing CERT Tapioca, Dormann introduces the use of CERT Tapioca in the automated discovery of SSL vulnerabilities in Android applications. Here is an excerpt: As mentioned in my previous blog post, one of the uses of CERT Tapioca is discovering applications that fail to properly validate SSL certificates for HTTPS connections. As a proof-of-concept experiment, I took an Android phone and loaded some apps onto it. By bridging the "inside" network adapter of Tapioca to a wireless access point, I was able to create a WiFi hotspot that would automatically attempt to perform MITM attacks on any associated client. Using a physical phone worked fine, and I was able to easily and quickly test a handful of apps. The problem is that this sort of testing environment doesn’t scale. The Google Play store currently has about 1.3 million applications, of which about 1 million are free. If it takes me 60 seconds to test each application, and if I’ve done my math correctly, it would take me a bit over 8 years to test each free Android application, assuming that I put in a 40 hour week for 52 weeks a year. While it was fun to test a handful of applications, I’m pretty sure that I would get bored before I made it through all of them. And I’d like to think that there are more valuable uses of my time. Automation to the Rescue Computers are great for performing tedious, boring work. Why not let them do the work? So how can we automate testing Android applications? First, I started with the Android Emulator that comes with the Android SDK. I installed it in a Linux virtual machine and created an Android virtual device. Because ARM Android is emulated rather than virtualized, it's very slow. So after the Android Virtual Device (AVD) completely powered up, I took a snapshot of the powered-on Linux virtual machine that it was running in. I also had an instance of CERT Tapioca providing network connectivity to the Android Emulator VM. The inside network adapter of Tapioca was connected to the same virtual network as the adapter for the Android Emulator VM. With that done, I wanted to control the AVD as well as the Linux OS running it. The complete post, Finding Android SSL Vulnerabilities with CERT Tapioca, can be read here. The remainder of this SEI blog post highlights the most visited posts on the CERT/CC blog in the area of vulnerability discovery. Vulnerability Discovery By paying greater attention to the early phases of the development lifecycle, CERT researchers aim to change the nature of the software development process to detect and eliminate—and later avoid—vulnerabilities before products are released. We work to achieve this goal by placing knowledge, techniques, and tools in the hands of software vendors to help them understand how vulnerabilities are created and discovered so that they can learn to avoid them. CERT researchers have developed a suite of tools to help vendors make more secure software. As the post below illustrates, researchers also try to help improve the public’s understanding of security concepts. In the post Differences Between ASLR on Windows and Linux, Dormann explains how one of the major exploit mitigations (ASLR) is different on the Windows platform vs. Linux. Here is an excerpt from the post: A program or library that is linked with the /DYNAMICBASE option will be compatible with ASLR on Windows. According to the Windows ISV Software Security Defenses document: In general, ASLR has no performance impact. In some scenarios, there’s a slight performance improvement on 32-bit systems. However, it is possible that degradation could occur in highly congested systems with many images that are loaded at random locations. The performance impact of ASLR is difficult to quantify because the quantity and size of the images need to be taken into account. The performance impact of heap and stack randomization is negligible. For this reason, there really is no reason to link anything without the /DYNAMICBASE option, which enables ASLR. With /DYNAMICBASE enabled, a module’s load address is randomized, which means that it cannot easily be used in Return Oriented Programming (ROP) attacks. When it comes to Windows applications, we recommend that all vendors use both DEP and ASLR, as well as the other mitigations outlined in the Windows ISV Software Security Defenses document. If vendors have not elected to use /DYNAMICBASE, users have the ability to force ASLR through the use of Microsoft EMET. The complete post Differences Between ASLR on Windows and Linux, can be read here. In the post Vulnerability Coordination and Concurrency Modeling, CERT researcher Allen Householder highlights recent work in the area of cybersecurity information sharing and the ways it can succeed or fail. In the introduction, Householder explains that in vulnerability discovery and cybersecurity information sharing work, he often learns the most by examining the failures in part because the successes are often just cases that could have failed, but didn’t.Here is an excerpt from the post: One of the first things you notice when you start thinking about vulnerability coordination is that there are more ways for it to go wrong than there are for it to go right. But we’ll get to that. It all starts with a vulnerability (vul). Let’s leave aside how that vul got there. We don’t really care. It’s simply a given for our model. Oh, right, we haven’t talked about models yet. Well, in this post I’m using Petri nets to demonstrate the coordination process. Petri nets are a way of modeling systems that operate with concurrency, and concurrency is often mentioned as one of the most challenging aspects of modern system engineering. If you’ve never seen a Petri net before, here is a quick introduction: Petri nets model distributed processes as a network of nodes and arcs. Nodes can be either places (circles), or transitions (boxes). Arcs (arrows) connect places to transitions and vice versa. Places can’t connect to places, and transitions can’t connect to transitions. Places can hold tokens, which mark the state of a process. Transitions represent events that change the state of the process. A transition can fire when all the places immediately upstream of it are occupied by tokens (i.e., when it is enabled). When a transition fires, it consumes tokens from its inputs and places tokens in its outputs. The complete post, Vulnerability Coordination and Concurrency Modeling, can be read here. In the final post in the vulnerability research area, Vulnerabilities and Attack Vectors, Dormann describes a few of the more interesting cases he has encountered through his research in examining attack vectors as a source for potential vulnerabilities. The post was published in 2013 and remains among the most popular on the CERT/CC blog. Here is an excerpt: Attack vector analysis is an important part of vulnerability analysis. For example, reading an email message with Microsoft Outlook can be used as an attack vector for the Microsoft Jet Engine stack buffer overflow (VU#936529). With the Microsoft Windows animated cursor stack buffer overflow (VU#191609), reading an email message with Microsoft Outlook Express in plain text mode can also be used as an attack vector. With both cases, it’s the analysis of the different attack vectors, not the underlying vulnerabilities that improve our understanding of the severity. Below are some recent examples where attack vector analysis took an important role. The complete post, Vulnerabilities and Attack Vectors, can be read here. CERT Vulnerability Notes In addition to the blog, another valuable public resource is the CERT Vulnerability Notes Database, which provides timely information about software vulnerabilities. Vulnerability notes include summaries, technical details, remediation information, and lists of affected vendors. Many vulnerability notes are the result of private coordination and disclosure efforts. Industry organizations cite vulnerability notices as part of technical notifications to customers and users. Visitors to the Vulnerability Notes Database can search for specific information, such as the 10 most recently updated vulnerabilities a list of vulnerabilities that affect control systems a list of vulnerabilities discovered using the Basic Fuzzing Framework (BFF) CERT researchers also provide an archive of all public vulnerability information from the database. Looking Ahead The past six months have been an important time for the CERT/CC Blog in terms of keeping our stakeholders informed and helping them protect themselves against ever-present cyber threats. The next blog post in this series will highlight the most popular post on the CERT Insider Threat blog, which aims to help organizations protect against insider threat. 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 For more information about CERT Tapioca or to download the tool, please visitwww.cert.org/vulnerability-analysis/tools/cert-tapioca.cfm.

One of my clients is the CEO of a small business that was doing very well. The business had been around for 20 years and had grown to a modest level in that time. At one point she felt the growth had become too stagnant and she felt she needed to make some changes in order to take the business to the next level. The problem was that those changes were bound to anger some of her staff. And she was a people pleaser. Luckily for her she had not been forced...