This requirement was put in place to prevent use of certain older C runtime functions that lead to buffer overrun flaws and have been deprecated. In the Security Development Lifecycle book, an entire chapter is dedicated to the topic of banned function calls. In the book, we also provide a copy of the banned.h header file on the companion CD. This header file allows you to locate any banned functions in your code.

On MSDN, we have document the SDL list of Banned Function Calls, but the header file has not been publicly available outside the SDL book until now. Today, we are providing the banned.h header on the Microsoft Download Center.

Find the banned.h header here

By including this header file, then using #include “banned.h”; you will be able to locate any banned functions in your code. The full list of banned APIs is also included in the header file.

Alternately, if you are using the compiler in Visual Studio 2005 or later, you have a built-in way to check for these banned functions. To catch banned C runtime functions, you can compile with /W4 and then triage all C4996 warnings. In code reviews, you should always remove any code that disables the C4996 warnings - e.g.: #pragma warning(disable:4996). This is one simple way to ensure your code is released without banned functions.

Sanitizing your code to remove potentially insecure APIs is a vital protection. Whether you include the banned.h header file or leverage the /W4-C4996 warnings in the Visual Studio 2005 compiler, you now have two ways to check your code and meet another SDL requirement in your development phase.

Preface

The TCP/IP protocols were conceived during a time that was quite different from the hostile environment they operate in now. Yet a direct result of their effectiveness and widespread early adoption is that much of today's global economy remains dependent upon them.

While many textbooks and articles have created the myth that the Internet Protocols (IP) were designed for warfare environments, the top level goal for the DARPA Internet Program was the sharing of large service machines on the ARPANET. As a result, many protocol specifications focus only on the operational aspects of the protocols they specify and overlook their security implications.

Though Internet technology has evolved, the building blocks are basically the same core protocols adopted by the ARPANET more than two decades ago. During the last twenty years many vulnerabilities have been identified in the TCP/IP stacks of a number of systems. Some were flaws in protocol implementations which affect only a reduced number of systems. Others were flaws in the protocols themselves affecting virtually every existing implementation. Even in the last couple of years researchers were still working on security problems in the core protocols.

The discovery of vulnerabilities in the TCP/IP protocols led to reports being published by a number of CSIRTs (Computer Security Incident Response Teams) and vendors, which helped to raise awareness about the threats as well as the best mitigations known at the time the reports were published.

Much of the effort of the security community on the Internet protocols did not result in official documents (RFCs) being issued by the IETF (Internet Engineering Task Force) leading to a situation in which "known" security problems have not always been addressed by all vendors. In many cases vendors have implemented quick "fixes" to protocol flaws without a careful analysis of their effectiveness and their impact on interoperability.

As a result, any system built in the future according to the official TCP/IP specifications might reincarnate security flaws that have already hit our communication systems in the past.

Producing a secure TCP/IP implementation nowadays is a very difficult task partly because of no single document that can serve as a security roadmap for the protocols.

There is clearly a need for a companion document to the IETF specifications that discusses the security aspects and implications of the protocols, identifies the possible threats, proposes possible counter-measures, and analyses their respective effectiveness.

This document is the result of an assessment of the IETF specifications of the Internet Protocol from a security point of view. Possible threats were identified and, where possible, counter-measures were proposed. Additionally, many implementation flaws that have led to security vulnerabilities have been referenced in the hope that future implementations will not incur the same problems. This document does not limit itself to performing a security assessment of the relevant IETF specification but also offers an assessment of common implementation strategies.

Whilst not aiming to be the final word on the security of the IP, this document aims to raise awareness about the many security threats based on the IP protocol that have been faced in the past, those that we are currently facing, and those we may still have to deal with in the future. It provides advice for the secure implementation of the IP, and also insights about the security aspects of the IP that may be of help to the Internet operations community.

Feedback from the community is more than encouraged to help this document be as accurate as possible and to keep it updated as new threats are discovered.

“The Afghanis, they live in mud huts, they don’t have electricity, they are stick-people weighing 85 lbs, and to say that we could bomb them into the stone age would be an advancement in their technology level.  But never underestimate these people, they’re survivors.  They’ve survived 35 years of warfare, starting with the Soviets, then they fought a civil war before we arrived on the scene.  Never underestimate their ability to survive, and have respect for them because of who they are.”

Today, I feel the same way about government employees, even more so because it’s an election year:  they’re survivors.

Now time for what I see is the “real” reason why the government is doing badly (if that’s what you believe–opinions differ) at security: it’s all an issue of culture. I have a friend who converted a year ago to a GS-scale employee and took a class on what motivates government employees. Some of these are obvious:

• Pride at making a difference
• Helping people
• Supporting a cause
• Gaining unique experience on a global-class scope
• Job stability
• Retirement benefits

And one thing is noticeably absent: better pay and personal recognition.  Hey, sounds like me in the army.

The Companion Family Plan for Survival at Home photo by Uh … Bob.

Now I’m not trying to stereotype, but you need to know the organizational behavior pieces to understand how government security works. And in this case, the typical government employee is about as survival-aware as their Afghani counterpart.

Best advice I ever heard from a public policy wonk: the key to survival in this town is to influence everything you can get your hands on and never have your name actually written on anything.

In other words, don’t criticize, be nice to everybody even though you think they are a jerk, and avoid saying anything at all because you never know when it will be contrary to the political scene.  The Government culture is a silent culture. That’s why every day amazing things happen to promote security in the Government and you’ll never hear about it on the outside.

One of the reasons that I started blogging was to counter the naysayers who say that FISMA is failing and that the Government would succeed if they would just buy their product for technical policy compliance or end-to-end encryption.  Sadly, the true heroes in Government, the people who just do their job every day and try to survive a hostile political environment, are giving credit to the critics because of their silence.

Which brings me to my point:

Yes, my name is Rybolov and I’m a heretic, but this is the secret to security in the Government:  it’s cultural at all layers of the personnel stack.  Security (and innovation, now that I think about it) needs a culture of openness where it’s allowable to make mistakes and/or criticize.  Doesn’t sound like any government–local, state, or federal–that I’ve ever seen.  However, if you fix the culture, you fix the security.

Bookmark to:

We represent situations in the domain of event processing by building and refining models of situations. This means that one way to develop CEP applications or designing CEP architectures is to define situations of interest and build models that define the situation.

After we have a working model of the situation we will generally have a hierarchical model of the situation composed of various components of the situation. For purposes of discussion I refer to this as situation modelling.

If a situation is modelled with 15 components then we need to detect these components of the situation. In addition, it is generally not good enough to simply detect each one of these components of the situation. We also have to hold the state of each one of the situational components.

However, it is not good enough to simply observe the state of 15 components of a situation in the detection process; we also need to observe the relationship between the components.

So, let’s say the situation we are looking for is “commercial air plane collision” and we are building a model of this situation. To keep the model simple we will limit the model to airplanes and omit objects like birds, buildings; but we will include wind, air speed, and direction.

Our situational model consists of primary objects, in this case an airplane. Now we need a simple model of an airplane, which is modelled, in this overly simple example, as span, velocity, acceleration, altitude, orientation and relative wind speed and direction. Generally, an object-oriented approach to model building is preferred so we can reuse the model and overload, morph, inherit and encapsulate as necessary.

One example would be when our boss comes to us and says, great job on the airplane collision model, but I also want to know how much jet fuel is on the planes at the moment of our projected situation, so we can estimate the intensity of the explosion. So we need another model and our earlier very simple airplane model would inherit the jet fuel tank model our boss requires.

I hope from this simple example of model building that you will conclude that modelling is one of the most important aspects of CEP. Without good models, situation detection impossible, and CEP engines are useless. Situation modelling is critical to CEP.

So, if a CEP vendor comes to you and says they have a very powerful CEP engine, ask them to show you a complex model of a situation that is important to you and explain to you how they represent the object. If models are not represented using an object-oriented approach, I recommend you send the vendor back to their software development lab, because without an OO approach to modelling, you can only represent very simple situations.

Furthermore, let’s say you are leading a team building a large model. If there are several teams working on various parts of the model, you need a common framework to integrate the work of the various teams. I strongly recommend an OO approach to your model building systems architecture and work breakdown structure.

In a future post, I will write about the companion to modelling – simulation

Well, the website for the NASA Phoenix Lander at least.

From the Register:

Add the webpages for the Phoenix Mars Lander to the list of high-profile sites that have been hacked by script kiddies. Not once, but twice.

Security pros had to take down the University of Arizona-hosted site after hackers replaced the lead blog entry with graffiti that read “hacked by VITAL.” As if that wasn’t enough, members of the self-declared “sql loverz crew” redirected baffled visitors of the Phoenix mission’s official webpage and a companion site to a third-party destination. That page gave credit to hackers going by the names BLaSTER and Cr@zy_king.

Red is the color of the Martian surface, but it seems it also describes the faces of security pros responsible for the sites. Evidently, they had better things to do than vet their scripts for SQL-injection vulnerabilities. So these hackers were willing to step in and test the sites for them.

Pesky SQL Injection attacks abound and the script kiddies are loving ‘em.

Article Link

The Eye-Fi Explore product relies on Skyhook Wireless's system of analyzing the signal strength of nearby Wi-Fi networks to extrapolate latitude and longitude. Eye-Fi ties that into their system to stamp images with locations. This deal also ties into Wayport's domestic network of 10,000 hotspots, most of which are McDonald's outlets, allowing free uploading via those systems. The purchase price covers one year of hotspot service. You can upgrade an existing Eye-Fi to the new feature for a fee. All three products work with Mac OS X Tiger and Leopard, and Windows XP/Vista.

Because Skyhook needs a live Web connection to look up the Wi-Fi environment, Eye-Fi can store the Wi-Fi snapshot when the picture is taken, and manage inserting the appropriate photo metadata (EXIF format) at upload for Flickr and other services that support geotagging.

Geotagging is a very popular idea, something that I'm quite taken with because it pairs the act of taking a photograph with the location at which the picture is taken, making a digital photograph seem a little less untied to reality. But until now, it's been generally quite involved to match a picture with coordinates. A handful of specialized cameras embed GPS chips, and there's software to facilitate other methods, but the cost and battery drain of GPS chips have apparently so far kept it from being a widely deployed feature, while the wonkiness of alternatives doesn't appeal to mainstream users.

Sony once sold this wacky GPS companion (which I just found out isn't available in either released model) that would track your location over time, and use that information to geotag images via a special software program that let you pair its stream of data with your photographs.

Eye-Fi and Skyhook are doing something almost the same, since the camera isn't capturing the GPS data, and the Eye-Fi isn't applying the information live, much of the time. But it's eminently more usable than the Sony system, because the Eye-Fi handles the assembly seamlessly for you.

Now there's just one thing to worry about. Think about this: McDonald's are everywhere, and nearly all of the U.S. locations have Wi-Fi. The Eye-Fi uploads whenever it can, as long as the camera is turned on. You're geotagging images without any effort. Okay, got it? So...you call in sick to work, and run off to take some photos. Your boss, using RSS to subscribe to your Flickr feed, not only sees your pictures as you wander the town, unknowningly promiscuously uploading them via quick-serve restaurants' networks, but also knows precisely where you are.

This makes me suggest that you might set your Flickr upload preferences to keep images private and your geotagging preferences the same. You can then expose the images you want for public consumption. The Panoptican is...us!

One of the phrases I often hear during vision and strategy planning meetings at Microsoft is "What is the crawl, walk, run?" We use this phrase to differentiate the initial activities that will get us quickly moving toward our larger goals and then supplement them with other activities that may require longer preparation or planning. As I help non-Microsoft companies implement SDL into their development lifecycles, this "crawl" phase toward full adoption of SDL is very important. Usually some person in an organization picks up on the principles of SDL and is ready to roll them out immediately. However, that person usually is faced with competing interests that complicate full adoption: the team is mid-stream in development, short on budget, or management wants to see clear evidence before investing in the changes to support full SDL adoption.

Since we usually focus on how to roll out the full Lifecycle, I want to take a shot at defining what it means to start “crawling” toward SDL. One very important note before I start. What I describe below is not Microsoft’s SDL process. It matches some of the tools and principles, but does not encompass the holistic application security solution provided by SDL.

In my mind, to start crawling toward SDL, you need to execute on some of the core principles. They obviously need to be low-cost and effective. So, I want to summarize these into three components.

1.       Detailed awareness of your architecture and its attack surface.

2.       Tools that will perform security analysis on your application.

3.       Results that show how the analysis resulted in improved security.

The good news is that you can attain these components with tools that are already available. The one consistent minimum requirement is that your code compiles/builds within Visual Studio 2005 SP1. The SP1 piece of this is important because some of the important defenses I discuss below were first made available in that version. Let’s look at some of the tools you can use to get “crawling” toward SDL today:

Detailed awareness of your architecture and its attack surface

Threat Modeling

Even if you are past the design phase, assign someone to do a retrospective model (perhaps as part of a pre-release review). This will likely give you a better understanding of your overall architecture and uncover holes in places you may have inadvertently overlooked.

Tools that will perform security analysis on your application

This is probably one of the most often discussed topics around SDL, so I’ll spend some time providing more detail. Let’s break this down into how it impacts differing parts of your team or organization: developers, testers, and operation.

Developers

You should start by strengthening your compiler defenses. Depending on whether you are writing native or managed code, these will differ.

For C and C++ code:

Strengthen your compiler defenses

·         Use the latest compiler and linker because important defenses are added by the tools

·         If using Visual C++,  use Visual Studio 2005 SP1 or later

·         Compile with appropriate compiler flags

·         Compile clean at the highest possible warning level

·         Compile with –GS to detect stack-based buffer overruns

·         Link with appropriate linker flags: /NXCompat to get NX defenses, /DynamicBase to get ASLR,  and /SafeSEH to get exception handler protections

Do not use banned APIs in new code

·         Use #include “banned.h” header file to find banned C/C++ functions in your code quickly. This header file is included in the companion disk in the Security Development Lifecycle book.

·         Compile regularly with /W4 and fix all C4996 (banned C Runtime function) warnings

For all Languages:

Strengthen your compiler defenses

·         Use the latest compiler, linker and libraries because defenses are added by the tools and code

o   If using C#, use  C# v2.0 or later and if using VB.Net use 8.0 or later

·         Use .NET Framework 2.0 or later

·         Do not use weak crypto in new code

o   Use only AES, RSA and SHA-256 (or better)

·         Prevent XSS vulnerabilities by using filtering and escaping libraries around all Web output

·         Secure your SQL script by only using prepared SQL statements - no string concatenation or string replacement

Run these tools habitually

·         PREfast (in Visual Studio 2005, use the /analyze compiler option) – a static analysis tool that identifies defects in C/C++ programs and enables you to perform quick desktop error detection on small code bases

·         FxCop – an application that analyzes managed code assemblies (code that targets the .NET Framework common language runtime) and reports information about the assemblies

·         Application Verifier (AppVerif) – detect and help debug memory corruptions, critical security vulnerabilities, and limited user account privilege issues.

Testers

James Whittaker has covered testing in the SDL on this blog in the past. In a “crawl” scenario, you need to keep it simple while maximizing the value of output. I would recommend focusing on fuzz testing. This is likely something you will need to invest some time creating.  Scott Lambert’s article on Fuzz Testing at Microsoft and the Triage Process provides some good guidance on how to think through what type(s) of fuzzing to exercise against your application.

If you choose to expand beyond fuzz testing, I would point you back to James’ article on the broader topic of Testing in SDL. You may come to the conclusion that expanded security testing  may come later in your “walk” or “run” phases, but I would take some time to think through testing even while “crawling” to ensure you are getting broad enough coverage for your application. James’ article highlights the three-pronged approach to security testing we use at Microsoft. You should use these three approaches to ensure your own fuzz testing is comprehensive.

1.       Attacks against the application’s environment.

2.       Direct attacks against the application itself.

3.       Indirect attacks against the application’s functionality.

Results that show how the analysis resulted in improved security

Response planning

Protecting your customers is the entire reason for focusing energy on application security.  If there are holes in your code that you don’t uncover, someone else will. It is absolutely critical that you are prepared to respond rapidly and protect your customers. It is equally important that you construct your  response plan to serve as a front-line barometer for detecting the resilience of your security design  and what pieces of your applications security should be proactively bolstered to  address externally reported vulnerabilities.  The knowledge you harvest from these security incidents (typically through root cause analysis) is the primary way to improve your code and security tooling for the future.  Do everything you can to learn lessons from the vulnerabilities others find. If you don’t have a response plan in place, you need to get one in place as soon as possible. If you don’t know where to start, take a look at how our own Microsoft Security Response Center does it and fit to your scale or pick up the Security Development Lifecycle book and dig into the four-step process outlined.

The four steps of the emergency response process:

1.       Watch

2.       Alert and Mobilize

3.       Assess and Stabilize

4.       Resolve

Bugs, Bugs, Bugs

Gathering evidence that clearly shows your work has improved the security of your application is always a challenge. Trying to keep it lightweight adds to that challenge. The most effective way to create traceable and practical evidence without a lot of overhead is detailed management of security issues in your bug database.  The key here is that your bug database is configurable and able to be queried in a variety of ways to pull out this data. From the time you set out to implement this plan, be strict in tracking every discovery from threat modeling, the mitigations to those threats, and every bug you expose in tool analysis. This library of security bugs will give you an easy way to go back and gather evidence that shows the quantity of issues you discovered, the mitigations you used, and the impact the changes had on your application.

I have provided a fairly detailed view of these components. As I indicated, many of these defenses are available for you in Visual Studio 2005 SP1 or various linked resources above. If you are unsure whether you are taking advantage of all available defenses in your development tools, take the time to check.

It is my hope that some of you can use this scaled back entry into the principles of SDL to get moving toward improved security assurance. In the non-Microsoft SDL engagements I have been involved in, we have seen these steps effectively establish a baseline architectural understanding of your application security and identify critical weaknesses while providing solid evidence to support the decision to “run” forward into full SDL adoption.

[I want to thank Michael Howard for providing some of the key data for the Developer pieces in this article.]

This is our final broadcast for 2007. This week's topic is Information Risk Management, an information-centric strategy that provides the most effective means of recognizing, assessing and mitigating the risk that information is exposed to throughout its lifecycle. Hear from a recent RSA Web Seminar conducted in collaboration with TowerGroup, on how financial institutions can leverage a sound IRM strategy. A companion white paper on the subject is also available.