TECHNOLOGY AREAS: Air Platform, Information Systems, Space Platforms, Human Systems

The technology within this topic is restricted under the International Traffic in Arms Regulation (ITAR), which controls the export and import of defense-related material and services. Offerors must disclose any proposed use of foreign nationals, their country of origin, and what tasks each would accomplish in the statement of work in accordance with section 3.5.b.(7) of the solicitation.

OBJECTIVE: Develop visualization techniques for planning and execution of Cyberspace operations.

DESCRIPTION: Fulfilling the Air Force mission “… to fly and fight in Air, Space, and Cyberspace” requires effective C2 tools for the observation, planning and execution of cyberspace operations. Conventional battlespace visualization tools were developed for the physical world (i.e., geospatially oriented), where the battlespace, weapons and effects are concrete, often observable entities. Cyberspace and its critical electronic infrastructures are an artificial world that must be created, modified and sustained by the warfighter. This artificial world of cyberspace has concrete links back to the physical world that shape the information landscape, affect the decision-making process, and control the communication channels crucial to C2.

Standard, geospatially oriented C2 tools are not suitable for providing cyber combatants with comparable situation awareness to understand events, evaluate options, and make decisions in the electromagnetic domain. The combatants in the cyber domain needs to be able to quickly see and understand not just the physical relationships of the traditional battlespace, but also the logical relationships and information dependencies in the abstract landscape of cyberspace. Cyber C2 visualizations need to provide information for strategy, tactics and execution of effects that may, or may not, have physical correlates. Examples of these cyber events include network attack detection, attack identification, damage assessment, denial of service (DOS) warnings, and information warfare or cyber-attack operations.

For example, a commander may be planning to intentionally disrupt a portion of his network to investigate a cyber-attack. He will need to understand what ripple effects will occur across the functionally diverse and geographically distributed network. These ripple effects will have both a cyber component (e.g., locations that will lose connectivity or suffer degraded performance characteristics) and a real-world component (e.g., information about enemy forces may be unavailable or delayed, reducing blue force effectiveness) that must be visualized, explored and tasked from within his C2 tools.

Decision makers will greatly benefit from innovative visualization tools that can improve their understanding of all aspects of the Cyber domain. These aspects include 1) the current state of the information environment, the physical and virtual battlespace and enemy and friendly capabilities and vulnerabilities; 2) the scope and scale of courses of action that affect information or information networks; 3) the primary effects and ripple effects of an operation in both the physical and cyber battlespaces, and 4) the risks for collateral damage associated with cyber warfare activities.

PHASE I: Identify cyberspace characteristics relevant to C2 visualization. Identify correlation methods and visualization techniques to understand battlespace, operations, and effects. Define metrics to evaluate efficacy. Document results in a written report, including mockups of proposed visualizations.

PHASE II: Construct a working prototype to demonstrate integrated visualization of cyber data showing 1) the status of information environment, 2) its effect on the conventional battlespace, and 3) the status of information operations. Evaluate effectiveness using metrics defined in Phase I.

PHASE III / DUAL USE: Military application: Additional military applications include command and control environments, like the Air Operations Centers (AOCs). Commercial application: Monitoring and defending infrastructures (e.g., financial and energy) against cyber-attacks. Visualization cyberspace is beneficial for security of commercial communication and information networks.

REFERENCES:

1. ‘Air Force leaders to discuss new ‘Cyber Command’

2. Laura S. Tinnel, O. Sami Saydjari, and Joshua W. Haines, An Integrated Cyber Panel System, IEEE Computer Society,

3. Anita D’Amico and Stephen Salas, Visualization as an Aid for Assessing the Mission Impact of Information Security Breaches, IEEE 2003.

4. Tim Bass, “Cyberspace Situational Awareness Demands Mimic Traditional Command Requirements,” AFCEA Signal Magazine, February 2000.

KEYWORDS: visualization, cyber, human factors, planning, situation awareness, command and control, HCI

Reference. SITIS Topic Details, Visualization for Command and Control of Cyberspace Operations

See also:  http://www.dodsbir.net/solicitation/sbir083/af083.doc

We have been conducting polls of our customers and of IT professionals at technology trade shows for the past two years and the results are in: Pulling together all of the management pieces and processes is even more crucial in a virtualized environment.

So what does this mean for you? You will need to refine your incident and problem management processes with new technologies in order to reduce downtime and maintain end user performance. But of course even the most basic technologies are not well integrated even in today’s world.

I recently participated in a Gartner Conference and watched to my amazement a real-time electronic survey of the audience. To my disbelief, the audience, filled with 300+ people from Fortune 2000 companies provided real-time responses to the question:

What level of integration does your IT org have between event management and service desk applications?

• None: 10%
• Manual Phone call from IT ops to IT service desk staff member: 46%
• Manual click button on event manager to open trouble ticket: 20%
• Automated event management system automatically opens trouble ticket without requiring human oversight or approval: 24%

Unbelievable… still very few of the survey respondents have yet to formalize problem management systems with event management systems. For 56% of the audience the process is still manual!

Another interesting real-time survey question at the Gartner Conference was:

Who in your organization is responsible for critical problem processes and resolution?

• IT Service Desk 13%
• IT Operations 49%
• Process Team 12%
• Other 9%
• Responsibility not formalized 17%

Virtualization adoption and the speed with which things change in a virtualized environment require automation and will transform Incident and Problem Management. Clearly with this new technology we are required to re-think Organizational, Behavioral and Cultural Challenges required to take advantage of the opportunities that virtualization provides.

Incident and problem management processes and metrics must bridge organizational silos that have been the norm within IT. With virtualization, people have to work more closely together in the different silos than ever before. IT leaders need to break down the walls between the technology-centric silo mentalities.

Business Imperative Action Plan:

1. What can you do today? –Understand the impact of virtualization on incident and problem mgt. workload, provide technology training for helpdesk/service desk staff.
2. What can you do in the next 12 months?

Formalize problem management processes, metrics and personnel.
Invest in tools and processes for systems on virtualized servers.
Long term: On the Radar Screen!
Instill teamwork into all groups responsible for the virtualized environment service and support. Map components and configuration items directly to end user services.

Final Thoughts: Know the management pieces and ensure that they fit together. It’s great to buy new technology, but be demanding to ensure that your vendors show you have they will help to link all these pieces together - Change, Inventory, Incident, Problem, Server, Capacity, Performance, Configuration, Event, and Integrated Workflow.

Wanted to drop a quick note to introduce the latest member of the SDL team - Katie Moussouris!

Many of you may already know Katie from her past work on the MSRC Ecosystem Strategy Team or her tenure at Symantec and @Stake.

Katie has joined the SDL team to help drive crucial elements of our SDL outreach effort; her primary responsibility will be managing our relationships with security consulting and training partners. She’ll additionally be tasked with ongoing analysis of the SDL – with a goal of assisting industry verticals that are looking to apply the SDL in critical computing scenarios. 

It goes without saying that she will be a regular contributor on the SDL Blog – but given her expertise, it’s likely she’ll continue to blog on an occasional basis over on Ecostrat...

Anyway – here’s Katie in her own words!

Katie Moussouris is a Senior Security Program Manager in the Security Development Lifecycle (SDL) Outreach Team, working to bring Microsoft’s SDL to partners, vendors and customers in order to improve the security of the Internet as a whole. Katie began her nerdy life programming her C64 in grade school, writing her own Zork-like text-based adventure – which was of limited use, since she had no friends and she knew all the puzzles in her own game.  Good thing she eventually left her room and found some like-minded people at a local 2600 meeting.

Katie’s professional background is application security, having come from Symantec by way of the @stake acquisition. Katie founded the Microsoft Vulnerability Research Program (MSVR), extending the focus of Microsoft’s security vulnerability research to third party software.  Katie also founded and ran the Symantec Vulnerability Research Program, the first program of its kind in Symantec's history to allow the publication through Responsible Disclosure of original vulnerability advisories discovered by Symantec researchers. In addition to performing security research, Katie has been an application penetration tester for Fortune 500 companies across numerous industries. She has uncovered serious vulnerabilities during the course of her work before they could be widely exploited by hooligans and criminals for either fun or profit, respectively.

Formalize your Final Security Review (FSR) Process

A Final Security Review is your final security audit to ensure your software is secure enough to deliver to your customers. I will assume the idea of an FSR is a new concept and try to provide some FAQ-style detail on this topic.

Who is the FSR team? An FSR Team usually consists of a non-product-team security expert (for impartial perspective), a security representative from the product team, and individual representatives from the separate disciplines. However, that size team may not scale to your company. If that is the case, at a minimum, you should have an impartial “outsider” separate from the product team who understands the security requirements as well as the measurements used to validate them. This person along with a project manager can probably perform the bulk of the FSR with development or test leadership providing input as needed.

What is needed to do an FSR? All threat models should be revised to reflect the final product, the code should be complete, and all security-related testing should be completed and documented. In addition, everyone involved in the FSR should have full access to the bug database to review status or exceptions to security bugs.

What does an FSR team do?

1. Re-review threat models to verify all mitigations identified in those exercises were fixed or went through an exception process.
2. Verify that all security issues uncovered during the development process were fixed or granted exceptions by the appropriate people. This is where you verify whether the state of your security bugs meets the “bug bar” requirements you have defined for your products.
3. If there is any output from security tools that you have used to define requirements, the FSR team would verify that the results of the tools meet the security requirements.
4. Review all exceptions to verify that they approve these decisions in the context of the final product. If they identify risks associated with the exceptions, they should communicate those to the business ownership for a final decision before signoff. Any decisions related to known risks should also be reflected in the response plan for future reference.
5. Finally, there should be a final signoff exercise where all security people and project leadership jointly approve the decision of the Final Security Review.

How long does an FSR take? If done correctly, the FSR will likely take some time. You should schedule this review well in advance of your release date to give your FSR team some time to complete the review, push issues back to the product team, and respond to any serious issues that may be discovered.

Final security reviews are a crucial piece to your Security Development Lifecycle. It would be easy to encourage secure development in your team, but as you expand your process to include formal security requirements and begin enforcing those requirements, it is necessary to perform a final audit of your product before it is released. Your customers will thank you for taking the time to add this layer of quality control to your operations and you will likely save yourself some security embarrassment down the road by adding a FSR to the end of your product cycle.

Document security work for reference

After the FSR is complete, there is still work for the security team. The final FSR documentation should be archived along with the symbols and code that represents the finished project. This becomes the time-stamped “snapshot” of your product. Your post-release process should include archiving the following documents in an easily accessible location:

·         All final threat models for future reference.

·         Bug bars, tool settings, and test results related to your project and the supporting tools used to validate. These will be referenced and reused in the next product cycle.

·         All documented security bug exceptions. These need to be rolled into your next product cycle to ensure they are addressed.

·         The final symbols that reflect the product shipped should be archived.

·         The Final Security Report and project signoffs to validate your security audit activity

·         Your Incident Response Plan (discussed in the Crawl post). This must be accessible for quick reference if security incidents occur.

Archiving this evidence serves a few critical purposes: it shows historic evidence of the work you did to ensure a secure product, allows you to postmortem the results and improves your process each time, and reduces the amount of time your team will have to spend next time around by making the existing resources reusable.

In closing…

I hope this long series has provided some practical steps you can take to move your Security Development Lifecycle practices to the next level. At Microsoft, creating a lifecycle to match security development practices has faced a fair share of challenges. However, the investment and time has resulted in more secure products. We’ll continue refining how we execute the Security Development Lifecycle and hope to share those ideas with you along the way. We welcome your thoughts and questions as you start “Walking” with the SDL in your own company and look forward to seeing more secure products and customers as a result.

I’ve created a unique tag on the SDL Blog to cover this series. To get a full list of the related posts, click the “Crawl Walk Run” tag on the left column. I’ll post a Word document version of the full “Walk” series sometime in the next week.