ESP: Nadie puede negar el esfuerzo que dedica Microsoft a la seguridad aunque haya gente que no lo aprecie. Por eso voy a dedicar este post a sitios Web sobre seguridad de la compañía que mucha gente no conoce y creo puede ser de mucho interés. Os recomiendo explóralos todos.  

US: No one can deny the effort devoted to security by Microsoft even if there are people who do not appreciate. I am going to dedicate this post to websites related to security by the company that many people do not know, and I think may be of great interest. I recommend you explore them all.

ACE Team Blog (http://blogs.msdn.com/ace_team/)

Threat Modeling Blog (http://blogs.msdn.com/threatmodeling/)

Information Security Tools (http://blogs.msdn.com/securitytools/)

Information Security (http://msdn.microsoft.com/en-us/security/dd547422.aspx)

Security Develop Center (http://msdn.microsoft.com/en-us/security/default.aspx)

Microsoft Security Development Lifecycle (SDL) (http://msdn.microsoft.com/es-es/security/sdl(en-us).aspx)

Patterns & Practices Security (http://msdn.microsoft.com/es-es/practices/bb190386(en-us).aspx)

SDL Blog (http://blogs.msdn.com/sdl/default.aspx)

BlueHat Blog (http://blogs.technet.com/bluehat/)

Microsoft Security Response Center (MSRC) Blog (http://blogs.technet.com/msrc/)

Security Research & Defense Blog (http://blogs.technet.com/srd/)

MSRC Ecosystem Strategy Team Blog (http://blogs.technet.com/ecostrat/)

Lately I have been doing training around the Microsoft prescribed threat modeling practice.  Today, in providing such a training, I realised the majority of my work has been focused around “what” the components are, but not as much about -how- to actually do a threat model.

To that end, I hereby offer some more pragmatic tips around the actual practice of threat modeling.

-

Not all Entites are Created Equal

In the world of threat modeling we like to identify and quantify “things”. These things range from, assets, actors, data sources, data flows, to processes and roles.  The purpose of knowing what types of entities these things represent is simple; Every entity represents and inherits different types of risk. Additionally, How and why entities talk to other entities represents risk.

In order to document entities and their relationships in a given context, Microsoft prescribes the usage of Data Flow Documents (DFD).  These DFDs are only a small handful of entity types that they’ve found describe the various “things’ inside of their systems.  Specifically they include; External Entities, Process, Data Store and Data flow.  A custom item to DFD is the red dotted line which represents where data is sent from one trust location to the next.

A simple data flow might look as follows:

Given the above, you can see how a user requests a login, the servlet passes the request to a login process, the login process authenticates to the database, and then flows backwards to the user who requested to login.  So far, this should be pretty straight forward.  But you might be wondering, okay after I created this how do I figure out what vulnerabilities I need to mitigate?  This is where the rubber hits the road.  Or, in other words, where the design hits STRIDE

What it Feels like

STRIDE is a classification system that Microsoft uses to identify risk types.  It stands for, Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, and Escalation of privilege.  By default, by simply BEING one of the aforementioned entity types, you inherit risk. For instance, by simply being an external entity, you inherit the risk of being spoofed and needed to be proven (repudiation) as that item.  On the contrary, data that is in transit (data flow) might be tampered with, read by someone who shouldn’t, or may be denied access to even work.

In Oct 2007 Microsoft released a diagram that better shows how that might look:

Keeping your Balance

• Using the STRIDE element diagram buys you some immediate traction on how to start looking at a DFD and making some informed decisions.
• Risks will further vary by understanding the actual type of element of each element, that is; a process which is a .dll will have different risks then one that is a windows service. Both can be spoofed, but the way in which spoofing could happen is different.
• The chart above was designed for Microsoft and it’s needs.  Build one for yourself to help YOU understand YOUR problems.
• The more experience your team has in security the better you will understand the various risks and threats to each element by it’s type.

* DFD image is borrowed from OWASP (http://www.owasp.org/index.php/File:Data_flow2.jpg)
* STRIDE image is borrowed from SDL Blog Article (http://blogs.msdn.com/sdl/archive/2007/10/29/the-stride-per-element-chart.aspx)

I have never thought of this.  After a breach, just blame the auditors.  Wait.  The reason I hadn’t thought of it is because passing a compliance audit IS NOT ASSURANCE OF SECURITY.  But some still don’t get it.

In an interview with CSO’s Bill Brenner, Heartland Payment Systems’ CEO, Robert Carr, blamed his QSA auditors for a recent (huge) breach.  Because they said his organization was PCI compliant, he felt secure.  Wow.  Security by checklist once again.

Rich Mogull, in an open letter to Carr, makes several excellent points about reliance on compliance instead of solid security practices.  He concludes his letter with,

But, based on your prior public statements and this interview, you appear to be shifting the blame to the card companies, your QSA, and the PCI Council. From what’s been released, your organization was breached using known attack techniques that were preventable using well-understood security controls.

As the senior corporate officer for Heartland, that responsibility was yours.

Source: An Open Letter to Robert Carr, CEO or Heartland Payment Systems, Rich Mogull, 12 August 2009

Rich’s letter is a good read, and it should be circulated widely among security professionals and senior executives. 

Among other things, this is another case where an organization is falling back on a completed checklist representing compliance with the PCI standard, a bare minimum set of security requirements.  But whether you are HIPAA, GLBA, or PCI compliant, checking off on recommended practices doesn’t equal security.

Each of us is responsible for placing compliance activities within the proper context: guidelines within a broader security program.  No regulatory or industry standards can protect our critical infrastructure or sensitive data.  Only an aware, thinking human who actually cares about security—and understands how standards apply within his or her unique environment—can do that.

The owners of AVSIM, an important resource for Microsoft Flight Simulator users, worked for 13 years to build a well respected site.  Using two servers, they conscientiously backed up one to the other, confident they were protected.  That confidence was shattered this month when a hacker destroyed the site, including both servers.  Since no offsite backup–or even an off-server backup–was available, it was impossible to recover.

There is a lesson here for all organizations.  If you have a server or other storage containing critical business information, make sure it is backed up to an offsite location.  Even if the probability is low that fire, tornadoes, hurricanes, and a host of other natural threats may take out your facility, there is always the hacker community which is always looking for a new challenge.

We always talk about the importance of offsite backups, but sometimes it takes an actual example to make managers sign a check.  Maybe that is the proverbial silver lining in this story.

As security management becomes more integrated into business processes, it’s commonly seen as closely related to risk management.  This is an accurate perspective, as security professionals position controls as ways to mitigate negative business events.  But risk seen in this way is often used as a monolithic tool used to hammer home reasons why executive management should spend more money on security.  Risk is actually an aggregate of many smaller factors which must be addressed if the business is to be adequately protected.  These smaller factors are often without cost in real dollars, and fixing them is a prerequisite for implementing more advanced controls.

Risk Defined

My take on risk is a little different from what you might be used to seeing.  I first start with a standard formulaic model and expand a little, as shown below.

Threats are pretty easy to understand when viewed in terms of all the ways people, malware in the wild, and nature can ruin a perfectly peaceful afternoon.  We’ll cover vulnerabilities later.  Target Value is defined in terms of either it’s criticality to the business or its sensitivity.  Sensitive systems and data typically include intellectual property, PII, or ePHI.  Finally, Response is a measure of how well an organization can detect, identify, contain a threat and recover from a security incident.  As shown in the formula, the effectiveness of an organization’s response directly impacts its overall risk. 

This is all very interesting, and it should be pretty familiar to most of you.  But there is another way of looking at risk which helps identify fundamental weaknesses in a security framework.

The Layered Risk Model

The layered risk model is something I use to identify the small things I may have overlooked.  It’s important to fix all the little things, things which taken all together can lower the ROI gained from implementation of sophisticated layered controls. 

In this diagram, risk is depicted as an aggregate of factors contained within four layers.  Each layer has its own level of risk, depending on how well elements within it are managed and what controls might be in place.  Although all are important, I’m focusing on the second layer (from the bottom) for the rest of this article.  For more information about the other risk factors, see A Practical Approach to Managing Information System Risk.

The Little Stuff

Since threats and vulnerabilities together comprise Probability of Occurrence, adjustment of either reduces the possibility of a successful attack.  We have little control over threats, so vulnerability management is our best option.  As you can see from this example, vulnerabilities exist in many forms.

In this particular model, I listed some basic security holes which I call the “little stuff.”  Little stuff in the sense each by itself may be a small vulnerability and is something which is easily addressed.  Together, however, they form a formidable vulnerability layer, easily exploitable by the right attacker.  They are also easily avoided by following fundamental security best practices. 

As the title of this piece infers, tightening a few screws–paying attention to the little stuff–can strengthen your overall control framework.  Once the wobbling ends, you can achieve a better understanding of actual gaps.

According to the recently released Microsoft Security Intelligence Report (2H2008), social engineering is taking the lead as the preferred method of network and end-user device malware infection.  Since operating system vulnerabilities are slowly disappearing and more organizations are implementing basic network controls, the easiest way to a target system is via the end-user.

Fear, Trust, and Desire (FTD)

According to the Microsoft SIR, users fall prey to social engineering attacks because of three common modes of human behavior: fear, trust, and desire.  As depicted in Figure 1, each of these behaviors is targeted by specially crafted attacks.

Fear is always a strong emotion, one often fed by media spin on Internet security, causing the average user to believe the end of civilization as we know it is at hand.  So it’s easy to understand why some panic when malware-induced messages appear on their desktops, telling them their machines are infected.  And the best—or only—way to remove the virus or worm, asserts the alert message, is by immediate purchase and download of the recommended AV software.  An example is shown in Figure 2.  Note the malware listed does not necessarily reside on the target system.  It’s just for effect.

Another method to lure a user is the promise of a trial version of a for-fee product.  These pages look authentic, as shown in Figure 3.  However, the result is the same.  The trial version displays a long list of bad stuff and prompts the user to purchase the full version to remove them.  So not only is a Trojan or some other malware loaded, but the user actually pays for the honor of hosting it.

Playing on the fears of users seems to be working very well.  Microsoft reports rogue security software is quickly becoming the Internet users’ biggest threat.  Table 1 lists the Top 25 malware loaded in this way.

In the midst of fear and uncertainty, users are continuously looking for a safe haven.  Thus the element of Trust.  Without the belief there is safety on the Web, no one except hard core techies would ever use it.  However, users often take trust too far, relying simply on the appearance of authenticity.  So when a page comes up which looks like their bank’s site, assumptions are made, passwords entered, and transactions executed.  In many cases, however, there is also the stealing of passwords, hi-jacking of sessions, or other revenue generating activity managed and controlled by an attacker.

Microsoft breaks trust down into different types.  I’m focusing on two: trust in institutions and trust in employer networks.  Again, bank sites seem to catalyze immediate trust.  This is a user behavior characteristic is actively exploited by cybercriminals.  Figure 3 is an example of a bogus bank site.  Routing victims to sites like this is typically done via phishing or DNS redirection.

In some cases, redirection isn’t necessary.  A Trojan installed on a user’s system can pop up a data entry window when an actual bank or other financial site is visited.  As shown in Figure 4, the pop up is used to collect information of value to revenue-centric attackers.

In addition to trusting external sites, users tend to believe their employer’s networks are secure.  After all, most organizations are at least talking-the-talk when it comes to protecting information assets.  This often lulls employees into that proverbial false sense of security.  So what not click on that link?  My company will protect me…

Finally, there is what I call the I-want-what-I-want syndrome.  Microsoft calls it Desire, but it means the same thing.  When a user wants something bad enough, whether business related or not, he or she is going to download and install it.  It doesn’t matter how much awareness training your organization has conducted.  Attackers understand this, using various media to lure users and hook them, especially “free” music, videos, and software with something extra added to make it worth the attacker’s time and effort.  Like a little rootkit with your free copy of X-Men?

What to do

The most important control has nothing to do with technology.  Rather it is you understanding these issues exist when you design your control framework.  It is understanding that human behavior is what it is.  It is taking steps to reduce human behavior’s impact by implementing technical controls which help mitigate or eliminate organizational or individual breach opportunities caused by user “mistakes.”

For more information about building user behavior mitigation controls, take a look at the following:

• Indirect malware detection: Probability verses Certainty
• Human behavior is what it is
• Preventing data breaches isn’t just about stopping stuff coming in
• Free Web content filtering puts safer browsing within reach for everyone
• Improve Data Protection Processes with Content Discovery, Monitoring and Filtering

As usual, finger-pointing about what is beginning to be seen as Conficker FUD is increasing.  Understandably, the media is taking the brunt.  Understandably, but not necessarily appropriate.

So let’s review.  The Conficker threat surfaced and media outlets did what they are supposed to do; they spread the word, supported by comments from security ‘experts.’  I for one want as much noise as possible when a new threat emerges.  The noise means I won’t somehow come late to the fray.  It also means senior management will be educated on the problem while I assess business risk.  So, what’s the problem?

Is it that many media pundits are not tech-savvy, and security experts compound the problem with unreasonable claims?

“It’s really complicated and media outlets have a hard time understanding it,” said Rick Wesson, chief executive of security company Support Intelligence, Wednesday. He earlier called Conficker a “digital Pearl Harbor.”

He has a point of course. Sensational stories sell. But every sensational Conficker story we’ve seen also quotes a few security experts making sensational claims.

Source: Conficker Scare: It’s the Media’s Fault, Ben Worthen, Digits (WSJ Blog), 1 April 2009

I don’t think so.  Regardless of whether a sky-is-falling situation exists, managers responsible for organizational security should know whether their controls are sufficient to repel a Conficker onslaught.  At most, a short assessment of its attack vectors and appropriate controls along those vectors should be enough to identify gaps and steps to fill those gaps.  Ideally, scenario planning activities have already identified related issues and they have been remediated.

As far as home users are concerned, most of them need an occasional kick-in-the-pants to ensure their systems are secure.  If it takes an occasional call to battle-stations, then so be it—even if the bogey turns out to be a harmless albatross.

Finally, we don’t know for a fact that Conficker is harmless.  It might simply be resting before its first real run at a target. As Worthen writes in his blog,

Conficker disclaimer: Just because the world didn’t end doesn’t mean that Conficker isn’t bad, and won’t do bad things in the future. Similarly, there are many other computer viruses out there that are currently doing bad things like stealing information.

So the problem was not with how Conficker was reported.  Rather the problem was with those responsible for maintaining secure systems not understanding whether they were at risk or not. 

It shouldn’t take a media frenzy to make people take a hard look at the state of their systems.  It should be an ongoing process, resulting in a strategy which provides reasonable and appropriate protection regardless of the latest emerging threat.

Although I agree that reliance on human behavior is not a good way to ensure information security policy compliance, it will always be a factor.

Technology is not the panacea for fraud or executive-level “cooking the books.”  A certain amount of human oversight is necessary to verify that application controls work properly, enterprising employees haven’t found a way around them, and the layered security infrastructure is working as expected.  Further, relying on a 100 percent technical response to an external attack is too costly and prone to being hacked.  So I don’t completely agree with comments recently attributed to Charles Cresson Wood, in which he appears to assert people must be completely removed from the compliance process.

During last week’s SecureWorld Boston, Charles Cresson Wood discussed the need to go beyond development of policy when implementing information security.  In his keynote address, he describes the need for systems which ensure compliance.

A huge problem is that security policies are still too reliant on people, Cresson Wood said.

“If you want a high level of compliance do not rely on humans to get the job done,” he said.

“Things are going too fast in information security. A manual response to distributed denial-of-attacks, for example, is inconceivable,” he added.

Scripted and automated compliance enforcement needs to be put in place, supported by intrusion detection, intrusion prevention and other tools, Cresson Wood said. Security appliances will be documenting and vouching for policies, producing admissible evidence that can be used if disaster strikes and legal issues ensue. “Something like a black box when an airplane goes down,” he said.

Source: Expert Cites Big Problem with Security Policy Compliance, Bob Brown, Network World, 25 March 2009

I agree that writing policies and training employees on what is and is not acceptable behavior is not enough.  I also agree that layered technical controls are absolutely necessary to achieve business objectives defined in the policies.  However, relying completely on technology to safeguard information assets  is a poor business decision.

A layered technical defense uses a variety of approaches to detect and prevent likely attacks.  Each safeguard is also configured to support other layers in case they are breached.  But note the key word here is likely.  It’s financially infeasible to attempt a prevention-only defense against all possible attack methods.  Instead, preventing probable attacks while detecting network or system anomalies makes the most business sense.

The success of  technical detection controls requires human monitoring of events and implementation of a documented and tested incident response process.  There must be a balance between human and technical controls.

So how does a security manager help executive management decide where the fulcrum lies when balancing human and technical controls when an unlimited security budget does not exist?  Easy.  Risk management.

Risk management assumes that the risk of a breach can not be feasibly reduced to zero.  So an assessment of probability of occurrence (derived from analysis of possible threats and known vulnerabilities) and business impact should be used to determine if sufficient controls–administrative, technical, and physical–exist.  In other words, has business risk been reduced to an acceptable level.  If it has, then the right balance has probably been reached.

Using this approach, is there a chance a breach will occur?  Yes, but enough detection controls should be in place to identify and react to it before serious damage is done.  We cannot expect organizations to completely lock down their networks with attack-prevention solutions.  The cost in both hard dollars as well as lost productivity is too high.

For more information on this topic, see Risk Mitigation Drives Breach Prevention Costs.

For years, large businesses have spent millions to improve information security.  Much of this expense was driven by regulation or fear of public relations issues.  As security around large networks and data repositories improved, however, many small and medium business (SMB) managers didn’t feel the need to spend money on security.  After all, only large targets get hit.  Why should they care?

The reason SMBs should care is simple.  They are typically softer targets than their big brothers.

As large organizations–once easy pickings for business-minded cyber-criminals–strengthened their defenses, the cost associated with unlawfully obtaining valuable information from them increased.  Along with cost increases there was also growing probability of being detected and arrested.  So criminals had to look for less expensive targets with lower personal risk.  They often found them among SMBs.

According to an article by Tim Wilson,

Hackers and computer criminals this year are taking a new aim — directly at small and midsize businesses, according to experts who spoke here today at Visa’s annual security event. The consensus: Smaller businesses offer a much more attractive target than larger enterprises that have steeled themselves with years of security spending and compliance efforts.

“As the security becomes better at large companies, the small business begins to look more and more enticing to computer criminals,” said Charles Matthews, president of the International Council for Small Business, in a panel presentation here. “It’s the path of least resistance.”

Source: Small Business: The New Black in Cybercrime Targets, Tim Wilson, DarkReading, 19 March 2009

This has always been the case, as depicted in an old joke about a bear.  You remember the one.  Two friends are in the woods when a bear starts chasing them.  The first friend begins to run as the second exclaims, “You can’t outrun a bear!”  The first friend replies, “I don’t have to.  I only have to outrun you.”

The same principle is working here.  For attackers to shift attention from large enterprise targets to SMBs, large network security doesn’t have to be perfect.  It just has to be stronger than the controls protecting SMB networks.  This makes extracting valuable information from SMBs less expensive, increasing attack ROI.  And since most SMBs don’t deploy detection systems, the risk of getting caught while in the act is much lower.

I’ve written previously about the problem with ignoring SMBs as a source of PII and ePHI breaches.  In many cases, SMBs also provide critical services to public and private entities, making their infrastructure availability as important as data confidentiality and integrity.  Hopefully it won’t take a series of publicized breaches against smaller organizations for everyone to get the message. 

And it isn’t just SMBs which have to start taking a closer look at security.  Once they’re locked down, the next softest, lucrative targets might include home networks.

Major Internet browsers were shown to be hackable this week at CanSecWest.  This isn’t really a surprise.  Browsers are malware portal opportunities waiting to be exploited.  What might be a surprise is that IT professionals might actually consider the browser a security layer.  It isn’t and probably never will be.

Browsers are by nature human created and managed mechanisms used to access applications written by one of millions of developers, developers often unknown to the user.  They access sites which may or may not be malicious, even if they appear to be hosted by familiar institutions we trust.  Finally, we can always count on the user to do something he or she has been warned many times not to do.

I’m not saying browser developers shouldn’t try to plug as many holes as possible.  However, there are too many variables when surfing the Web to ensure reasonable and appropriate browser trustworthiness.  So what is the answer?

We should stop trying to make our browsers perfect and begin examining the effects of various attack vectors.  This provides the information necessary to select appropriate security controls to layer between the browser, sensitive data, and the network.  Examples include anti-virus, personal firewall, and host-based intrustion prevention software.

Going beyond the desktop, we need to revisit the Internet’s security overall, starting with DNS.  Until we can ensure the most fundamental services are reasonably secure, the security of our browsers is at most a secondary concern.

We should also assume a breach will eventually occur.  Until humans are replaced by design and development cyborgs incapable of making mistakes, and until security budgets are doubled or tripled beyond that which is considered reasonable and appropriate today, there will always be gaps between our actual security state and 100 percent protection.  So in addition to trying to prevent malicious intrusions, we should also implement technology and processes to detect and respond to extrusions.

I’m not saying we should ignore weaknesses in browsers, or any software.  However, it’s unreasonable, and possibly negligent, to point fingers at browser vendors while ignoring the part we should play in protecting our organizations from browser-based attacks.

Reports of data breaches aren’t uncommon.  And explanations are typically slow in coming, but most large organizations fall on the proverbial sword and admit their security controls played a role in presenting an opportunity to the attacker.  However, the Comcast approach seems a little different… take no responsibility and blame user carelessness.

Comcast now believes a phishing or malware scam is to blame for exposing hundreds of its customers’ user names and passwords. A list containing around 8,000 names was discovered by a PC World reader this week and brought to the company’s attention.

The list, which had been posted on document sharing site Scribd, was found by Kevin Andreyo — a educational technology specialist and university professor in Reading, Pa. Andreyo read our recent report on people search engines and decided to follow its suggestions to see what kind of dirt he could dig up on himself. While detailed personal information is common to those types of searches, Andreyo never expected to come across his actual user name and password for his Internet service provider.

Source: Comcast: Exposed User Data Not From Internal Leak, PC World, 17 March 2009

This might have happened, but how can Comcast be sure.  First, only 700 of the 8000 names were current.  The rest were either duplicates or old, inactive accounts.  So could this account information have been phished from unsuspecting users?  Absolutely.  But Comcast shouldn’t stop there.

If the managers at Comcast were truly concerned, if they aren’t actually blowing this off as a user ignorance issue, they should be aggressively looking for possible open attack paths to systems on which current customer information resides.  This would be more productive than what they might be doing… trying to pull the wool over our eyes.

What do you tell your boss when you try to get additional—or any—breach control dollars into the IS budget?  How do you position these controls to demonstrate business value?  If you aren’t talking in terms of business risk, you might be pounding harder on the table than necessary.

Most seasoned security professionals know there is no way to completely protect a network and sensitive information from a highly motivated attacker.  Rather, the goal is to reduce the risk of an attack.

Read the entire article at CSOonline.

What is Threat Modeling?

Threat modeling is an engineering technique you can use to help you identify threats, attacks, vulnerabilities, and countermeasures that could affect your application. You can use threat modeling to shape your application’s design, meet your company’s security objectives, and reduce risk.

Several enterprises are increasingly investing time and money in building application security tasks into their existing SDLCs. Some of them have also reached the conclusion that proactive approaches , like threat modeling, have more ROI than reactive approaches. As a result, some enterprises with nascent appsec programs have turned to threat modeling as a panacea for their security problems. However, threat modeling may not be the solution to their immediate problems. Now I recognize that this may be a controversial statement.

Recently, I have been involved in several situations where organizations with their heart in the right place have made threat modeling mandatory as part of the development process, with limited success. My point is that threat modeling as part of a mature SDLC is a desired end state though not necessarily the initial step. Let’s examine this argument.

Firstly, threat modeling depends on several elements of a SDLC to be fairly mature. Most importantly it depends on requirement and specification gathering process to be rigorous. Also, an enterprise must have well defined standards and policies in place to act as input into the threat modeling process. Without these elements of the SDLC in place, the threat modeling process will be isolated and have a reduced impact.

Secondly, a threat model is a security plan only and is useless without any committed follow-up action as part of development and testing. Most enterprises do not allocate sufficient time and resources to implement the findings of the threat model. A large portion of organizations don’t even have a security assessment team in place. These teams are consumers of the threat modeling process that actual carry out the most crucial task of reducing risk by implementing countermeasures.

Thirdly, it is practically feasible to create threat models only for new projects or those undergoing incremental changes. As a result, legacy applications do not benefit from threat modeling. This leaves a huge gap in the enterprises’ risk profile.

Finally, most nascent application security programs need quick and demonstrable ROI. The threat modeling process ROI can take several months or even years to be quantifiable because it is an incremental process that is dependant on several other SDLC processes to be effective. There are other areas where investment can bring in more immediate ROI. These areas include security assessment team, security training for developers and definition of countermeasures for  common vulnerabilities.

For organizations with nascent application security processes, I recommend that they us the following framework to evaluate if they are ready to adopt threat modeling:

• Does a security baseline exist?
• Is the SDLC process fairly well defined and followed during development?
• Has the organization agreed upon countermeasures for common vulnerabilities?
• Are developers trained to avoid common vulnerabilities?
• Do developers do a self review of code for security vulnerabilities?
• Does a security assessment team exist?

If the answer to more than two of the questions above is no then the organization is probably not ready for adopting threat modeling.

A widely held notion among computer scientists is that 80% of a programmer’s time is occupied maintaining code while the other 20% is spent actually writing the software. This inefficient allocation of effort was the subject of a master’s thesis at the Lund Institute of Technology called “Formalizing Use Cases with Message Sequence Charts.” According to a 2002 NIST study entitled “The Economic Impacts of Inadequate Infrastructure for Software Testing“, the annual cost of testing and fixing buggy software in the U.S. is estimated to be between $22.2 and $59.5 billion. What are the root causes of this costly inefficiency?

Unfortunately, corporate culture is naturally a contributing factor for this problem. Companies that produce commercial software are in business to make a profit first and foremost. Release schedules are expedited so the program can be released to market quickly and copies are sold sooner rather than later–making code work as expected for baseline use cases takes priority over regression testing. Any aspect of the software development process that does not appear to be fully in-line with company interests is considered a waste. Usually, far too much emphasis is put on project progress. The overall progress is only perceived progress because unforeseen problems will inevitably pop-up later on. In the long run, bugs end up costing much more to fix down the road and the entire business apparatus pays the cost of maintenance. Some secondary losses are customer support costs, internal communications and a negative impact on the company’s public image all of which can be preempted by proper preliminary work.

Since there’s so much emphasis on speedy release code writing starts as soon as possible, often with disregard to planning ahead beforehand and ensuring quality afterwards. Furthermore, programmers tend to implement items that they are most familiar with first because it seems like the easy way to do things. In most cases, the most difficult parts of a task are best handled first, not last. Handling the difficult items first allows more time and attention to the important stuff; it also allows the developer to recognize how the simpler pieces will fit into the grand scheme of things.

Planning ahead is an essential during the inception phase of a software project. Appropriately analyzing the problem and carefully designing the solutions will minimize the accumulation of technical hardships in the future. In fact, by taking advantage of the popular Unified Process for software development and diagramming specifications in UML the need for writing code almost disappears. UML CASE tools such as IBM’s Rational Rose will translate UML diagrams into program source code (typically an object-oriented language such as C++ or Java.) Of course creating detailed requirements and specifications is still extremely helpful even if UML is not practical for the task at hand. Writing code early on gives the illusion that progress is being made but in reality it is a recipe for disaster. No code should be written until all implementation issues have been resolved.

Threat modeling and secure design principles need to be key focal points during the initial phases of a software project. After the code has been written security issues will also comprise a large chunk of ongoing maintenance work. When software developers handle security fixes they have to stop what they’re doing, modify or maybe even rewrite the offending code, test the new code, report their progress, etc. Since developers are rarely security specialists, they tend to write fixes in such a way that the security hole is not closed completely. As a result, the vulnerability persists and leads to more code rewriting. This cycle of stopping, rewriting, and continuing severely detracts from productivity in programming. The majority of a developer’s time should be spent doing what they do best–adding new features to software.

Removing developers from the patch creation process significantly increases their utilization. Dedicated security experts are most fit to create patches and conduct regression testing. A dynamic program analysis tool accelerates the regression testing process. Building security in by default from the ground-up will minimize software bugs along with subsequent patching and testing. In conclusion, proper planning, resource allocation, and testing procedures can greatly reduce the costs associated with software regression.