Exploiting the business cycle

The federal reserve has announced its quarterly outlook, and decided not to change Interest rates.

The terse statement can be read here.

The press release mentions as little as possible, but one thing it mentions is “Business spending on equipment and software has risen significantly” while spending on construction is still depressed.

This is what you expect from the “business cycle”. Unemployment stays high after every recession. Instead, companies produce more with the same number of workers by increasing worker productivity. In other words, businesses invest in capital equipment (e.g. robots) and software to make workers more productive. It is this increase in worker productivity that causes the relative wealth of our country (and the lack of productivity is the cause of poverty in poor countries).

What does this mean for us computer geeks?

It means that the time to start a company is often at the bottom of a recession. Because of layoffs, it’ll be easier to find employees. You busily develop your product during the recession, and then release it as we come out of the recession – at precisely the right point of “significant” investment in software/equipment.

The same applies to security geeks. Our skills are too specialized to fit as normal employees in a lot of companies, so a lot of us are consultants instead. During the uptick after a recession, companies don’t like increasing their payrolls, but they will hire consultants. Right now is (theoretically) a good time to be a security consultant.

Some Large Website Please Do This Study

There was an Internet-scale blackout last week. No, it wasn't caused by a worm, but instead a buggy virus signature in McAfee products that disabled svchost.exe in WinXP SP3. The effect was the same as a worm; hundreds of thousands, if not millions, of machines were affected.

We don't yet know the scale of this event, but there is an easy way to find out: User-Agent strings at popular websites. There should be a dip in WinXP systems accessing websites compared to other systems (because disabling svchost.exe crashes the system, and it cannot be rebooted until the file is restored through a complicated manual process). Popular websites can measure that dip in order to figure out how many systems were affected by the buggy virus signature.

The popular web-browsers (IE, Firefox, Safari, Firefox) put the operating system version in the User-Agent string. This is always “Windows NT 5.1” for WinXP. The previous version, Windows 2000 is “Windows NT 5.0”, and the following version, Windows Vista, is “Windows NT 6.0”.

Huge websites like Google log the User-Agent strings. They can easily create a report of the relative popularity of WinXP for each day. The relative number of WinXP machines will drop. A large enough website should be able to figure out precisely how big that drop was, and therefore, a good estimate of the number of machines affected by the bug.

McAfee originally claimed that the bug was minor, and only affecting less than 1% of their enterprise customers. They had to latter amend this, and admit that more were affected, but they still downplayed the severity of the bug.

I don't believe them. The bug disabled ALL machines running WinXP SP3, which is by far the most popular operating system in enterprises. Even if an enterprise has mostly transitioned to something like Windows 7, they will still have a lot of machines running WinXP SP3. I would guess that virtually all large enterprise customers of McAfee were affected to at least some extent, and that many were completely disabled for the day.

An independent study can confirm my suspicion. Please, if anybody works for a large web-site, please do this study. Or, if you don't have the resources, I'll come in an do it (I'll sign all appropriate NDAs and such). I really want to know the answer.

"That's not the lesson!!" Lessons unlearned from the Blippy CC number exposure.

If you didn't read about what happened to the social media site Blippy this week, they've explained it better than I will here. Basically 5 credit card numbers were exposed to Google. Two unnamed small banks pushed the number to Blippy's system in a way that is not consistent with any other bank, and therefore Blippy had not accounted for it in their first beta. The issue with these numbers is now resolved, and the question remains, has the damage already been done?

If you didn't read the actual statement from Blippy transparently explaining the problem and how they fixed it, you're not alone. On Twitter especially, there was a flood of retweets exclaiming "I told you so! It's obviously a crazy idea!" without any real information. This company was figuratively set aflame in the eyes of the web. As someone that has studied identity theft extensively, I have been watching Blippy from the beginning, and what I can't stress enough here is "That's not the lesson!" We should NOT be treating this incident as proof that Blippy is a bad idea, because this incident DOESN'T prove that.

In the Information Security community especially, I was shocked to see how many people didn't get why this is scary. Bugs happen. In the age of the Web App, bugs are public. They get fixed, and people are made whole. What concerns me here is the lack of flames set towards Google for caching those numbers in the first place. The numbers were NOT accessible from blippy.com, they came from google.com. Google has the ability to edit their cache, and scrub CC numbers, yet we are not demanding this from them. How did we get to this point where we tar and feather an innovative start-up company, while the big guy behind the curtain gets no critique?

InfoSec community, I expected more from you. Instead of mounting a campaign to find out who the banks were and offer to improve their payment card practices, we sent out LOLz in the Echo Chamber and acted like brats. In the hopes that we redeem ourselves from this display of clueless elitism, I am calling out the the community to start this discussion:

How can we protect Blippy and make the credit card companies embrace this new class of user?

It's a public world, and people are sharing their lives, whether we think they should or not. We need to start facilitating this change, not just saying "No" because we don't understand this industry.

Vuln Disclosure is Rude

It's amazing that after all this time, our community has not come to grips with "vulnerability disclosure". Last weekend, a lot of people tweeted the following scenario from this Attrition blog post on the difficulties of vuln disclosure:

ME: "Hi, you left your headlights on."
NEIGHBOR: "WHO SENT YOU? DID MY EX-WIFE SEND YOU? ARE YOU SLEEPING WITH HER?"

The intent of this is to show how badly people react to "friendly" disclosure of vulns. However, vuln disclosure isn't friendly. It is an inherently rude act. It's more like writing "WASH ME" in the dirt covering a person's car. Your standard of cleanliness may differ than your neighbor's. Pointing this out will always get a hostile reaction.

What vuln researchers expect is something like the following scenario:

ME: "Your hairstyle is ugly."
NEIGHBOR: "Thank you for telling me. I'll go to the hairdresser and fix it immediately."

That's not going to happen. I mean, try it with your neighbor. I'd bet that you'll get a hostile reaction rather than the desired one above.

The reason vuln disclosure is rude is because most people don't care about fixing security problems. This includes not only the vendor, but also the customer. Sure, the customers care when vulns cause a problem, but frankly, most vulns don't cause problems. For the average small software vendor, no hacker will ever exploit even obvious vulns in their products. I know this because people hire us all the time to find vulns. We find the most shockingly obvious things that have been in their products for years, yet going back through logs we fail to find any evidence that malicious hackers have found and exploited those problems.

Security is a tradeoff. When a small company fixes a vuln, it comes at a huge cost. It means fixing something that their customers largely do not care about (and would not pay for) at the expense of adding new features that customers would want (and pay for). When a researcher publishes a vuln in a product, it a previously harmless vuln becomes harmful, forcing a tradeoff to be made that neither the vendor nor the customer wanted.

It's hard for vuln research to grasp the enormity of the tradeoff. For us, security is easy. We can pentest a product and come up with an obvious vuln within seconds. Here's a real scenario: we were asked to look at a product, so we put a packet-sniffer on the wire and within seconds found a secret password being sent in the clear that would allow us to own all their customers. Yet, for the small software vendor, this is black magic. Nobody in the company knows how to use a packet-sniffer, nor is there any budget to hire somebody who can. Nobody understands really how to fix the problem that isn't equally insecure. Their development process is so crappy that they can't track this bug and make sure it's fixed.

Vuln disclosers believe that such problems wouldn't exist "if only people took security seriously". That's not the issue. I could hold a gun to your head and tell you to solve a third order differential equation. No matter how seriously you took my threat, you still would not have the ability to solve it. Sure it'd be straightforward for a mathematician to solve, but essentially impossible for everyone else. Vulns are straightforward for us, but still impossibly difficult for most vendors.

The Attrition blogpost linked above focused on the idea of "responsible disclosure". Vuln researchers can be extremely rude while cloaking themselves in "responsibility". For example, you often see vuln reports where the researcher claimed that the vendor ignored their vuln. That's not precisely true. What really happens is that researchers act in passive-aggressive ways to make sure that the disclosure process goes awry. Sure, the immediate response of any vendor is to deny a problem (especially small vendors that have never dealt with a vuln before). Polite researchers try to overcome this hurdle in a positive fashion, passive-aggressive researchers exploit this to show why the vendor is evil or stupid. The Attrition article is a good example of the passive-aggressive attitude: when disclosure awry, it's always the vendor's fault and never the researcher's.


While disclosure is always "rude", it is never "irresponsible". Take Internet worms, for example. Regardless how responsible the underlying vulns were disclosed, they resulted in devestating Internet worms. The result was that vendors learned a lesson and stopped shipping product with such a large attack surface. While it's impossible to justify the value of disclosing a single vuln that caused a billion dollars in damage, overall, the disclosure of such bugs clearly improved cybersecurity.

It's like how there is no such thing as "irresponsible speech". It's hard to say why particular speech is valuable, such as burning a Koran, but overall, any laws that restrict "irresponsible" speech end up restricting good speech. That's why laws banning "insulting" end up banning legitimate criticism of political leaders.

Therefore, we should not delude ourselves that we are helping the vendor (or their customers) with a disclosed vuln: we usually aren't. We should not justify our actions by calling it "responsible disclosure". We should understand the inherent rudeness of our actions and behave in a humble manner. Yet, while the vendor will hate us, we should still disclose such vulns, because unfettered security research serves the greater good.

UPDATE by David Maynor (5:08pm EST): The more people involved, the more likely it'll go awry. Vulnerability Disclosure is like sex: it should be between 2 people, 3 max. Any more participants will result in a big mess of hurt feelings, bruised egos, NDAs and a weird feeling in the pit of your stomach anytime it is mentioned.

What kind of company is Apple?

I was reading Apple's quarterly report. For the first time, iPhones are the largest part of their business. The details are:

$4.45-billion - computers (Macintoshes, MacBooks, Xservers, etc.)
$4.56-billion - iPods, iTunes store, etc.
$5.58-billion - iPhones etc.
$1.10-billion - other

Apple started out as a "computer" company. Then, as their iPod sales surpassed their computer sales, they became an "entertainment" company that also made computers. Now they are a "mobile phone" company that also makes computers and entertainment products.

This is also the first time iPhone sales have surpassed BlackBerry's. The latest report from Research in Motion (RIM), maker of the BlackBerry, was $4.08-billion for the entire company. The iPhone has long outsold Palm's as well. That's interesting because Palm and BlackBerry were the original "smartphone" companies, and Apple came late to the market. It's because the iPhone was the first one that really worked, that allowed you to browse the "real internet" rather than a cellphone version of the Internet.

As far as I'm concerned, proper Internet access is no longer a luxury, but a necessity. The market for smartphones is growing, and I bet that Apple's share of that market will remain constant. I bet that this side of their business will be the fastest growing for the next few years. (When I say "I bet", I mean "I've purchased a large chunk of Apple's stock".)

Jobs has promised a new "big thing" for later this year. Does he mean the iPhone 4, or does he have something else up his sleeve. Smart televisions are the next big market. Already, the average big-screen LCD has wifi built in with a video decoder that can pull files from home servers. Yet, televisions are still complex with all the possible inputs and outputs. I think the time is right for Apple's legendary ability to simplify things that people think cannot be simplified and fix this situation. If I had to bet, this is what I would guess as Apple's next-big-thing (which would shift their company back into the entertainment category).

This Week in Boston: SOURCE Boston and Security B-Sides

April in Boston is like July in Las Vegas or March in San Francisco. It's the time when the horde of security folk descend upon the East coast for half a dozen security events. Among the list of too many to name is BeanSec tonight, SOURCE Boston Wednesday through Friday, and Security B-Sides on Saturday.

SOURCE has many exciting speakers this year, including Andrew Hay, Rich Mogull, Dino Dai Zovi, Ron Gula, Josh Corman, a keynote from HD Moore, and many more. The event I'm most looking forward to is the Mentor Workshop. New this year, the Mentor Workshop features almost 20 different industry experts who are offering their time as a mentor for the up and coming members of our community. I'll be contributing to an opening panel about mentoring starting at 5:00pm on Wednesday in Seaport Ballroom B along with David Mortman, Erin Jacobs, Dan Guido, and moderated by Kees Leune. I hope to talk about internships specifically, since that process was so helpful in my own introduction to the security field.

Since its inception last year during BlackHat, the Security B-Sides events have been my favorite part of going out to conferences. The event in Boston, with the hashtag #BSidesBOS on Twitter, will be held at Microsoft's New England Research and Development Center on Saturday from 9:00am to 7:00pm. Here the talks will be on three tracks, with speakers like Mike Dahn, Michelle Klinger, and Joseph Sokoly on the main tracks, and one extra track for breakout discussions TBD on Saturday. I'm hoping to start a breakout about security training for application developers, since that's what I have been so engrossed in these past 6 months. If you'd like to chat about that with me, be sure to get to B-Sides Saturday morning and toss in a vote. Admission is free, thanks to the awesome sponsorship of Astaro, RSA, Rapid7, Adobe, IOActive, and BigFix.

Buffer overflow attack on YouTube! TGIF!

Happy Friday everyone!

Just when you think the "Awareness vs. Policy" debate can't get any more entertaining, I saw a great example of security awareness in the wild that shows people are really starting to get the message.

In The Cleveland Show, Season 1 Episode 16, Cleveland Jr. uses a buffer overflow to hack into the YouTube file system, and then a backdoor to bypass the criminal investigation database authentication. Pretty sweet.

How did Wikileaks decrypt the video?

Now that I'm reading mainstream press on the incident, I notice some people asking what Wikileaks means by its claims that it somehow broke the encryption.

The answer is "nothing much". There are two types of encryption: serious, and casual. If the file were seriously encrypted, then Wikileaks would not be able to break it, no matter how much computing power they had. On the other hand, if the file were casually encrypted, then it could be broken by a desktop computer in an hour.

A typical example of casual encryption is WinZip. One of the options is to encrypt your file using a password. I use this sort of encryption all the time. If I want to send sample computer viruses to other security researchers, I’ll zip them up with the password "infected" so that the e-mail virus scanners won’t block them (and to inform the recipient to take care).

It’s easy to crack this encryption. There are lots of zip-cracking packages out there that will attempt to decrypt the file by trying all the words in a dictionary. E-mail gateways don’t do this because they can afford to spend an hour trying to crack a single file, nor do they want to delay e-mail that long. But this doesn’t mean the file is seriously "secure".

I could instead choose to be serious about encrypting the zip file. I could choose a longer password like "7dh73hdHkLe)dn@hn!xoq3%axhgGK:V3tgh(kjg%3fjkfQl[" and AES encryption, and feel confident that even the master spies in the government would not be able to decrypt the file, not even with their billions of dollars of computing power. The only way to break this sort of password is if somebody leaks it -- in which case it's even easier to decrypt than using a dictionary of common passwords.

The important thing about cracking such encryption is that the problem is exponential. A 12-character password is not twice as hard to decrypt as a 6-character password -- it is instead a trillion times harder. If a single computer can decrypt a 6-character password in an hour, then it would take that same computer 100-million years to crack a 12-character password. An 18-character password would be a trillion time more difficult than even that. If you pick a long password, with random characters, and correctly encrypt something, then no amount of compute power will be able to crack it.

Wikieleaks says:

Have encrypted videos of US bomb strikes on civilians http://bit.ly/wlafghan2 we need super computer time http://ljsf.org/

I can’t imagine what this means. Either they have the power to decrypt now, or no amount of donations will buy enough compute power. The boundary between these two extremes is vanishingly thin.

To the right is a picture of the exponential growth of passwords containing 100 possible characters. As you can see, the graph appears to go straight up. Short passwords can easily be cracked by a desktop computer, but after the graph shoots up, all the super computers combined won't be able to crack them. There is only tiny bit in between where a super computer can crack the password, but a desktop cannot.

If they wanted to decrypt the video, they could simply post the file as-is. White-hats like me might find a way to bypass the encryption (e.g. if they used the insecure CRC32 encryption in older zip files rather than the new AES). Or, black-hat hackers with million-node botnets can run a distributed cracking program that would provide more super computer power than donations to Wikileaks could ever buy. Even if they didn’t want to post the entire file, the first few kilobytes would likely be enough.

UPDATE: But aren't there a lot of research papers that use need super computers, such as the cracking of MD5 certificates last year? Yes, but that's a different problem. Research is by definition on the bleeding edge. Whatever they do is impractical a few years ago, and doable on a desktop a few years hence.

UPDATE: Wired confirms the guess that the file was in an encrypted ZIP file.

"Collateral Murder": why Wikileaks sucks

(This post updated here for the cablegate leak)

In theory, Wikileaks is exactly the sort of organization I'd like to support. What makes modern civilization work is that government is transparent and accountable to the people, and a site posting leaks will make government even more accountable.

That video is exactly the sort of thing I'd like to see leaked. It showed two things. The first was an embarrassment to the military. The second was proof that they improperly denied a FOIA request – there was no “national security” grounds for denying access to that video, which we can all plainly see.

Despite this, I won't be donating money to Wikileaks. The reason is that they have no integrity, no honor.

The ideal “leaks” site would be one that doesn't take a sides. A good example of this is similarly named Wikipedia: their rules forbid taking sides, and when bias creeps in, they point it out. A lot of articles have a warning above them declaring "The neutrality of this article is disputed".

Neutrality is important because there are always two sides to an argument. No matter how evil or corrupt, the other side has their point of view. Hitler had a point view. Stalin had a point of view. Saddam Hussien had a point of view. When I was a kid, I read "To Kill a Mockingbird", whose theme was the importance of understanding another person's point of view, to "walk a mile in their shoes". This important concept applies not only to the downtrodden in life, but to everyone, including soldiers and CEOs.

THE OPPOSING POINT OF VIEW

The Army investigated this incident, and has produced a report (“6--2nd Brigade Combat Team 15-6 Investigation.pdf")

These helicopters were not joy riding looking for people to kill. Instead, they were part of a battle that had already been going on for 4 hours (by the time this video was taken). All non-combatants had either fled the area or hid in their basements – anybody walking around in the area was likely a combatant.

Except for the two reporters, these were insurgents. They were carrying machine guns and RPGs. You can see this in the Wikileaks video. Near the start of the video is the shot where the camera zooms in on the reporters, believing their camera bags were actually weapons slung over their shoulders:

A few seconds later, however, the camera moves up a bit showing the guys following the cameramen. Those guys are clearly holding weapons in their hands, one holding a short weapon that looks like a machine gun, and another holding what looks like an RPG. You can't really see it in the still picture I show below, but when you watch the video, it's obvious that gun-shaped objects are swinging from their right hands (download the video from Wikileaks and see for yourself!).

According to the Army investigation, when foot soldiers arrived at the scene, they indeed found RPGs and machine guns on the dead insurgents (and cameras on the dead cameramen).

Reuters tells cameramen that they should wear something identifying them as press. These cameramen didn't follow that recommendation. If they had, there is a good chance that the pilots a hundred yards away would've realized that they had cameras, and it was cameras slung over their shoulders, and not weapons.

When our soldiers decided to fire, it was because those guys with the RPGs walked behind a building out of sight, then somebody appears to be furtively aiming something around a corner. Most people agree that this was a cameraman with a huge telescopic lens, but even know that, it still looks to me more like somebody aiming an RPG at the helicopter.

Why were the children injured? Nobody is necessarily to blame, but it as much the consequence of their parents decision to drive into a combat zone as it is the soldier's decision to prevent a suspected insurgent from escaping.

I don't like the occupation of Iraq, and I'm not standing up for the soldiers. Their joy in killing is hard to stomach. However, I have watched the video multiple times. Our soldiers neither targeted the journalists or the children. Instead, they fired upon a group insurgents clearly carrying weapons during a larger battle. The journalists died, and the children got injured, because they were mixed up with insurgents.

Whether firing on the van helping (what is believed to be) an insurgent escape is still a salient question here.

CONCLUSION

Our Army was clearly wrong in withholding this video. It's exactly the sort of thing that should be revealed by FOIA requests. Reuters rightly tried to make the Army accountable for the killing of it's journalists. There is a clear question about whether firing on the van was justified. It's certainly embarrassing, but that's exactly the point of transparency. I'm glad that a “leaks” site exists to reveal such things.

But this post isn't about the incident, but about Wikileaks.Wikileaks is partisan, with no integrity. In their edited video, they highlight the cameramen, but they don't similarly highlight the guys carrying RPGs/machine-guns. They describe this as “indiscriminate slaying of over a dozen people” in an Iraqi suburb, when I can see clearly that they were firing on insurgents holding weapons during a 4 hour battle. In a Twitter post, they describe the Army investigation report as “bunk”, when it clearly is a good description of what went on. This partisan approach to “leaks” is not the sort of thing I want to see.

It's not simply partisan, but greedy. Their front page also encourages donations. The more they can distort the contents of leaks like this, the more money they stand to make.

UPDATE: I've just started reading "mainstream" media coverage of this video. Apparently, others have the same sort of criticisms that I have. For example, in this NYTimes article are the following bits:

The site is not shy about its intent to shape media coverage, and Mr. Assange said he considered himself both a journalist and an advocate; should he be forced to choose one, he would choose advocate. WikiLeaks did not merely post the 38-minute video, it used the label “Collateral Murder” and said it depicted “indiscriminate” and “unprovoked” killing. (The Pentagon defended the killings and said no disciplinary action was taken at the time of the incident.)

...
Critics contend that the shorter video was misleading because it did not make clear that the attacks took place amid clashes in the neighborhood and that one of the men was carrying a rocket-propelled grenade.

Mr. Assange has to choose between "journalism" (which I would eagerly donate money to) and "activism" (a poison people like me would never support).

UPDATE: Wikipedia now has a page dedicated to the July 12, 2007 Baghdad airstrike. Whereas Wikileaks uses the word "murder", Wikepdia uses only the word "kill". Wikipedia describes the situation with passion or prejudice.

Legal Alert: Court Slaps Back at FCC "Net Neutrality" in Comcast Case

by Elizabeth Wharton*

In a direct hit to its "Net Neutrality" proposals, a federal appeals court ruled today that the Federal Communications Commission ("FCC") lacks the authority to "regulate an internet service provider's network management practices." A unanimous three-judge panel of the U.S. Court of Appeals for the District of Columbia Circuit held in Comcast Corp. v. FCC, No. 08-1291, that the FCC failed to prove it had the statutory authority to interfere with Comcast Corp.'s network management practices and vacated the 2008 FCC citation against Comcast.

In a decision that is expected to move forward to the Supreme Court, the FCC must now evaluate whether other "Net Neutrality" principles can continue to be enforced. Under this decision, regulation of internet services is not permitted. The court cited that while regulation of common carrier services, including landline telephony, radio transmissions, cable services, and broadcase television are covered through the Communications Act of 1934 (as amended), cable internet service and internet service are not covered. The FCC had argued that their authority stemmed from section 4(i) of the Communications Act, granting the FCC the ability to perform any acts, rules, regulations and orders as necessary in the execution of its functions. The FCC claimed that Comcast's decision to limit use of large bandwidth peer-to-peer networking applications violated the FCC's Internet Policy Statement. Under the FCC's Internet Policy Statement, consumers are entitled to lawful internet access of their choice and use of applications and services they choose. Comcast countered that their interference with the peer-to-peer programs was necessary to manage network band-width capacity.


The 36-page decision released today followed oral arguments in January.

*Legal-E: My Views From the Bar. I am a lawyer, just not yours - My posts are intended to present issues from my point of view and are not intended to be advice, legal or otherwise.

The First Steps to a Career in Information Security

Last week I talked to the students of Georgia State University's CIS/InfoSec program about things they should be doing now to prepare for an exciting career in information security. Most of the steps they already knew, so I tried to think of the things that nobody told me in school that really helped me.

Here's my 15 minute presentation to the class. Below that is a summary of the talk and the links that I mentioned.

Errata Security releases the results of the survey on secure coding practices

Errata Security released the results of a survey conducted over the week of Security B-Sides and the RSA Conference in San Francisco. The survey found that Microsoft SDL was the most common security development lifecycle chosen of the companies using formal methodologies, but Ad Hoc solutions are still more popular. Small companies are more likely to be using Agile development, and the corresponding SDL-Agile. The most common reason for not choosing to use a formal methodology was resource requirements. Of those that responded they were choosing not to use a secure coding program, a lack of resources was by far the most common answer. No matter what the size of the company, participants said it was too time consuming, too expensive, and too draining on their resources. Another reason was that management had deemed it unnecessary. Management plays a key role in these decisions. The survey showed that developers look to management to set the security agenda, and are generally not self-starters when it comes to including security in their code. Security in the SDLC is still a relatively new methodology. 43% not integrating security is a high number, but it's improving at a steady pace. The adoption of SDL-Agile, which was introduced in November '09, by almost all of the small development shops and several large companies shows us that people are ready to make the shift, they're just waiting for the right style to fit their needs. Here are the press links covering the story, and a link to the actual paper: Download the Survey Results (pdf): "Integrating Security Into the Software Development Lifecycle" Dark Reading: "Survey Says: More Than Half of Software Companies Deploying Secure Coding Methods" CSO Security and Risk: "Code Writers Finally Get Security? Maybe" Microsoft SDL Blog: "Survey Results: Microsoft SDL awareness on the rise" Jeff Jones Blog: "SDL AWARENESS AND ADOPTION HIGH AMONG SECURITY PROFESSIONALS" Help Net Security: "Root issues causing software vulnerabilities"