I used to react to this with "Are you stupid?! PCI being prescriptive is the best thing since sliced cake :-) Finally, there is some specific guidance for people to follow and be more secure!" BTW, in many cases end users who have to comply with PCI DSS still think it is "too fuzzy" and "not specific enough" (e.g. see "MUST-DO Logging for PCI"); and they basically ask for  "a compliance TODO list." (also see this and especially this on compliance checklists)

But every time it happens, I can't stop but think - why do people even utter such utter heresy? :-) And you know what?  I think I got it!

When people say "PCI is too prescriptive," they actually mean that it engenders "checklist mentality" and leads to following the letter of the mandate blindly, without thinking about WHY it was put in place (to protect cardholder data, share risk/responsibility, etc). For example, it says "use a firewall" and so they deploy a shiny firewall with a simple "ALLOW ALL<->ALL" rule (an obvious exaggeration - but you get the point!) Or they have a firewall with a default password unchanged... In addition, the proponents of "PCI is too prescriptive" tend to think that fuzzier guidance (and, especially, prescribing the desired end state AND not the tools to be installed) will lead to people actually thinking about the best way to do it.

So the choices are:

1. Mandate the tools (e.g. "must use a firewall") - and risk "checklist mentality", resulting in BOTH insecurity and "false sense" of security.
2. Mandate the results (e.g. "must be secure") -  and risk people saying "eh, but I dunno how" - and then not acting at all, again leading to insecurity.

Take your poison now?! Isn't compliance fun? What is the practical solution to this? I personally would take the pill #1 over pill #2 (and that is why I like PCI that much), but with some pause to think, for sure.  I think organizations with less mature security programs will benefit at least a bit from #1, while those with more mature programs might "enjoy" #2 more...

BTW, this post was originally called "Isn't Compliance Fun?!"  I had a few fierce debates with some friends and all of them  piled on me to convince me that "compliance is boring, while security is fun!" The above does illustrate that there are worthy and exciting intellectual challenges in the domain of regulatory compliance. It is not [only] a domain of minimalists (who just "want the auditor to go away") and mediocrity, as some think. What makes security fun - the people aspect, the ever-changing threat landscape, cool technology, high uncertainty, even risk - also apply to compliance ...

So, need a cool marketing slogan BUT hate "making compliance easy"?  Go for "Making Compliance Fun!" :-)

All posts on PCI - some are fun:-)

"We are looking at something verging on the incredibly bizarre. As she got older she got shorter and broader and was reduced to a giant gelatinous blob, carrying many thousands of eggs," he says.

"Her shape was likely to have affected her behaviour and ability to hunt. I can't imagine her jetting herself around in the water at any great speed, and she was too gelatinous to have been a fighting machine.

"It's likely she was just blobbing around the seabed carrying her brood of eggs, living on dead fish, while her mate was off hunting."

Synopsis:  Blue Box #81: iSkoot vulnerability, OFCOM legislation, VoIP security news and more

Welcome to Blue Box: The VoIP Security Podcast #81, a 42-minute podcast  from Dan York and Jonathan Zar covering VoIP security news, comments and opinions.   

Download the show here (MP3, 19MB) or subscribe to the RSS feed to download the show automatically. 

NOTE: This show was originally recorded on May 21, 2008.

You may also listen to this podcast right now:

Show Content:

• 00:20 - Intro to the show, contact information and how to provide comments.  Welcome to all the new listeners - and to all those listeners who have been here for so long!
• Programming notes:
  • Note about the hiatus
• Voice of VOIPSA: Are your Skype username and password completely exposed if you use iSkoot?
• Voice of VOIPSA: Chronology
• Voice of VOIPSA: iSkoot disclosure of Skype credentials resolved – new version by Wednesday
• Ofcom confirms VoIP providers must provide access to 999 and 112 – and Hannes Tschofenig points to 4th Emergency Services Coordination Workshop and presentation about the UK
• MarketingVOX: British Proposal May Force ISPs to Fork Over Online Activity, Emails, VOIP Calls pointing to Reuters article: Britain mulls plan to store all email and calls
• Enterprise VoIP Planet: VoIP Security: SIP-Versatile but Vulnerable


• IT Business Edge: Pay Attention to VoIP Security Before The Storm
• NetworkWorld: Business Guide to VoIP Security


• Pocket-lint: Fraudsters targeting VoIP Users based on report out of Newport Networks (reported in VoIP News) – also covered at Fierce VoIP: Newport Networks riles up VoIP Security Fears and Computeractive: Phreak-out over VoIP and TechHerald article


• Network World: Security and management considerations when deploying OCS


• LXer: Secure Calling Initiative Reaches Second Milestone pointing to Secure Calling Initiative



• [H]Enthusiast: Mobile Phones, VoIP Not Secure, Experts Warn=



• VoIP News: The Essential Guide to VoIP Privacy



• Voice of VOIPSA: Information Week interviews SecureLogix about VoIP security


• eWeek: VoIP Security through Responsible Software Development


• Microsoft gives back door keys to Vista to police


• Comment (blog) from Martyn Davies


• Comment (email) from Detlef


• Comment (email) from Dan McGinn-Combs


• Review of the last week's traffic on the VOIPSEC public mailing list 


• Wrap-up of the show


• 41:43 - End of show 

Comments, suggestions and feedback are welcome either as replies to this post  or via e-mail to blueboxpodcast@gmail.com.  Audio comments sent as attached MP3 files are definitely welcome and will be played in future shows.  You may also call the listener comment line at either +1-415-830-5439 or via SIP to 'bluebox@voipuser.org' to leave a comment there. 

Thank you for listening and please do let us know what you think of the show.

Synopsis:  Blue Box #80: VoIPShield vulnerabilities, what is ethical disclosure?, SIP trunking, VoIP security news, new nomadism, and much more...

Welcome to Blue Box: The VoIP Security Podcast #80, a 44-minute podcast  from Dan York and Jonathan Zar covering VoIP security news, comments and opinions.   

Download the show here (MP3, 19MB) or subscribe to the RSS feed to download the show automatically. 

NOTE: This show was originally recorded on April 21, 2008.

You may also listen to this podcast right now:

Show Content:

• 00:20 - Intro to the show, contact information and how to provide comments.  Welcome to all the new listeners - and to all those listeners who have been here for so long!
• Programming notes:
  • Note about the hiatus
• Voice of VOIPSA: Are your Skype username and password completely exposed if you use iSkoot?
• Voice of VOIPSA: Chronology
• Voice of VOIPSA: iSkoot disclosure of Skype credentials resolved – new version by Wednesday
• Ofcom confirms VoIP providers must provide access to 999 and 112 – and Hannes Tschofenig points to 4th Emergency Services Coordination Workshop and presentation about the UK
• MarketingVOX: British Proposal May Force ISPs to Fork Over Online Activity, Emails, VOIP Calls pointing to Reuters article: Britain mulls plan to store all email and calls
• Enterprise VoIP Planet: VoIP Security: SIP-Versatile but Vulnerable


• IT Business Edge: Pay Attention to VoIP Security Before The Storm
• NetworkWorld: Business Guide to VoIP Security


• Pocket-lint: Fraudsters targeting VoIP Users based on report out of Newport Networks (reported in VoIP News) – also covered at Fierce VoIP: Newport Networks riles up VoIP Security Fears and Computeractive: Phreak-out over VoIP and TechHerald article


• Network World: Security and management considerations when deploying OCS


• LXer: Secure Calling Initiative Reaches Second Milestone pointing to Secure Calling Initiative



• [H]Enthusiast: Mobile Phones, VoIP Not Secure, Experts Warn=



• VoIP News: The Essential Guide to VoIP Privacy



• Voice of VOIPSA: Information Week interviews SecureLogix about VoIP security


• eWeek: VoIP Security through Responsible Software Development


• Microsoft gives back door keys to Vista to police


• Comment (blog) from Martyn Davies


• Comment (email) from Detlef


• Comment (email) from Dan McGinn-Combs


• Review of the last week's traffic on the VOIPSEC public mailing list 


• Wrap-up of the show


• 41:43 - End of show 

Comments, suggestions and feedback are welcome either as replies to this post  or via e-mail to blueboxpodcast@gmail.com.  Audio comments sent as attached MP3 files are definitely welcome and will be played in future shows.  You may also call the listener comment line at either +1-415-830-5439 or via SIP to 'bluebox@voipuser.org' to leave a comment there. 

Thank you for listening and please do let us know what you think of the show.

More specifically, his prospects either just blow him off by saying "pah, who needs this logging crap" or they profess their undying love of all things logging - and then still don't buy his product (which is priced, shall we say, "to go" :-))

Admittedly, these are the companies that form the core of today's botnets (thru sheer idiocy - and a generous helping of resource/skill shortage!) and enable RBN to deliver high-quality malicious services to criminal enterprises worldwide, which is no mean feat. Still, if you happen to have thoughts along the line of "who needs logs?" or "ah, logging? it will come later!", you really deserve a nice fat check from RBN and other malicious "hacking" syndicates since it is extremely likely that your overall attitude towards security is just as misguided (Did I just invent a metric called "logging as a litmus test of security program maturity"? :-))

But how to move from such ... what was before the Stone Age? ... Sharpened Stick Age? to modernity? Most companies go thru the following in regards  to their logging:

1. Deep log ignorance: "Logs? What are those?"
2. Shallow log ignorance: "Later...later...later... #37 on the TODO list."
3. Log collection: "We gather and store dead log data...cold."
4. Log searching: "We will dig into the pile when we have to ... hopefully never!"
5. Log analysis and reporting: "We know our logs - and what they mean"

(also see my post "Natural Flow of Log Management" for some specifics)

Of course, compliance (PCI DSS and others) help move people from 1. and 2. to 3., but - here comes the punchline! - people often get stuck at 3. or 4. and never progress to Logging Enlightenment of 5.

Yes, PCI DSS and other regulations mandate not just log collection, not just dead cold log storage, but also log review, (daily, in case of PCI DSS Requirement 10) but "review" happens to be the item that gets overlooked  all too often.

Why???

I think the reason is that log analysis is still too hard and still not automated enough for an average organization. Yes, I did see some corporations that built their own log analysis systems that - surprise! - exceeded the best available from the vendors [at the time]. However, a typical company IT department would not have Ph.D. poring thru some text mining research papers in order to improve their home-grown log analysis AI. They expect the vendors to  eat the logs, chew on them for a bit - and then spit out the answers.

Are we there yet? No, but we will be!!

First, let me say what I knew about the SDL going in: no policy can anticipate every situation; you have to make tradeoffs; the details matter; the big picture matters; you need tools; you need human insight; you need management support; and we’re never going to be perfect. All of the things you’ve read in this blog are true, and they really shouldn’t be controversial. Since joining SQL, I’ve learned a lot about SQL Server too, and what it means to ship a product - but that’s outside the scope of this blog. So instead, I’ll try to describe three real experiences that illustrate things that shouldn’t be controversial either, but aren’t usually covered under the rubric of security.  They are crucial nonetheless.

Security is not the point, it’s the needs of the customer. It’s easy to believe that security is the point of producing a product. It’s not. We won’t produce an insecure product, but the primary driver for a product team is to produce a valuable, useful product. Yes, security is a big part of that, but security is not a goal in and of itself.  For example, one of the areas of fierce competition in enterprise database products is performance, and we have to balance security with  performance. One of the ways we do that is by verifying data we receive really well, but only when necessary. We define clear trust boundaries, and check the data thoroughly once on the way in, and then work very hard to enforce those trust boundaries.

I first encountered this in SQL when I helped review threat models for the database engine. The engine trusts that the data on the disk was written correctly by a trusted entity (with checksums to guard against random errors), and enforce that. Instead of a slavish adherence to the principle of total mediation or defense in depth, which, when taken to its extreme would say to “check everything, every time,” we are hard core about making the right checks, but only the right checks.

I will note that it is not an either/or choice between security and performance – it is possible to do both. Indeed, I would say that doing one without the other is pointless, but to get both 1) world class performance, and 2) world class security,  you have to understand your data flows really well, and make detailed decisions.

Be polite, but don’t be afraid: Job interviews at Microsoft can be challenging. When I interviewed for this job, my final interview was with a very senior architect. The subject of integer overflows came up, and he asked me to describe the problems and solutions. So I started writing some code on the whiteboard. After about 10 minutes of describing my approach to integer overflows, he said to me, “What if I were to tell you that’s a really bad solution, and the interview is over?”

My heart sank.

But instead of rolling over, I said, “well, that’s a bad outcome, tell me why.” He proceeded to attack my solution on several grounds, including being unreadable and unmaintainable, and he proceeded to describe his solution to the problem. Now, this was a very serious, very senior technical architect, and I was in a high pressure, asymmetric situation. So, not willing to be intimidated, but unable to attack back, I pointed out several shortcomings of his solution, politely, but firmly. And we spent the next 40 minutes talking about various aspects of the problem, and me defending my solution, which I think was credible. I don’t know if he agreed with my solution or not, really, but I suspect it might have been a test to see if I would cave. Or maybe he thought it really was a bad solution, I don’t know. But I got the job.

As a security professional, you’re always going to be at a technical disadvantage when you’re reviewing another team’s components. They designed and implemented the system. You are an outsider, and it is absolutely impossible to understand the system to the degree as the people who built it. Nonetheless, you’ve got to find a way to ask hard, probing, impolite and sometimes even uninformed questions without being threatening or insulting, or undermining your own credibility.  

Be polite, be firm, put your ego in a box, and ask questions until you understand.

“It should work” is not a good answer:  We take the giblets problem very seriously, and managing giblets can be quite difficult at times. And in SQL, we have lots of giblets. We consume things from Windows, and Office, and Visual Studio, and others, and we provide giblets to other teams as well. In fact, we provide components that other teams use to build the giblets they provide to us – we consume our own giblets!

And as it happens, one of the components we use was updated recently. Even though it would get serviced through Microsoft Update, we want to ensure we have the latest and greatest version of any component we ship. But to consume the latest and greatest version of this particular component would require some small updates to either our installer or theirs. So we met with the team that owns the giblet in question to try to divvy up the work, and to avoid schedule disruptions on either side.

There was a lot of back and forth about various things to try, and we continued to refine a solution until we had reduced the problem to a single issue. 

At this point, there was an air of hope in the room. If the idea actually worked, we had a solution at relatively low cost. But would it work? When the question of “will this work” comes up, all eyes turn towards test managers.

Our general manager was looking right at our test manager and she asked, “Will that work?” The test manager looked across the table at the development manager from the other group, and said, “I don’t know. That depends on their level of confidence in the behavior of their component under these conditions.”

Now, all eyes were starting at the dev manager, and the room got quiet. A somewhat sheepish look came over his face, because he knew the answer he was about to give would be unsatisfactory. He said, “Well, I’m not a tester, I’m just a developer, but it should work.”

At which point the room erupted into hysterical laughter.

“It should work” means “I think so, but we have to test it.” And that means the whole battery of tests for each of the affected components, across all of the supported platforms. And that has to be scheduled in test labs. To be clear, this wasn’t a lack of confidence in the developer, quite the contrary, he was laughing along with everyone else. We just know that writing software to satisfy all the scenarios in which our software is deployed requires far more testing than can reasonably be performed on a single desktop system.

So the tests were scheduled, the developer was proven correct, and we’re picking up the latest version. Even seemingly simple changes require a lot of testing.

So, that’s what I’ve learned: security isn’t the be-all-end-all,, things are really complex and hard to understand, and you don’t really know if anything works until you test it. None of which should be controversial, but none of the central ideas in the SDL are controversial either. The hard part is putting theory into practice, and recognizing that no venture is risk free, despite the natural inclination of security engineers to avoid any risk whatsoever. In this, I am reminded of one of my favorite books, “To Engineer is Human: The Role of Failure in Successful Design,” by Henry Petroski. He writes, “No one wants to learn by mistakes, but we cannot learn enough from successes to go beyond the state of the art. Contrary to their popular characterization as intellectual conservatives, engineers are really among the avant-garde. They are constantly seeking to employ new concepts [and are] constantly striving to do more with less. [] The engineer always believes he is trying something without error, but the truth of the matter is the each new structure can be a new trial. [] Such is the nature not only of science and engineering, but of all human endeavors.”

While Cynthia Rothe-Seeger (the district judge on this case) opinions are obviously technically questionable given that many of these tools are written specifically to find public information (that means available for anyone, including anti-spam organizations) this could set a legal precedent that enables spammers to operate with near legal impunity out of North Dakota. Great. So if you or someone you are investigating is based out of North Dakota - I’d watch this lawsuit until this is settled. Talk about taking one giant leap backwards for mankind. So fierce is off limits to you North Dakotans!

66.249.73.40 - - [26/Nov/2007:01:53:58 +0000] “GET /blog/?%22%3E%3Cscript%3Ealert(1)%3C/script%3E HTTP/1.1″ 200 55053 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”

Not too bad for a robot. How about some totally innane Apache directory structure stuff that couldn’t possibly work?

66.249.73.40 - - [26/Nov/2007:00:46:03 +0000] “GET /bluehat-spring-2007/?C=S;O=A HTTP/1.1″ 200 3681 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”

Someone needs to figure out how UTF-7 works:

66.249.73.40 - - [26/Nov/2007:02:25:19 +0000] “GET /s.js+ACIAPgA8-/script+AD4-x HTTP/1.1″ 302 204 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”

Oh don’t we love the Google spam? I really am disheartened that it’s this easy to con Google into spamming websites. As if I don’t get enough referrer spam, Google does one better. *sigh*

66.249.73.40 - - [23/Nov/2007:19:11:23 +0000] “GET /weird/popup.html/Buy-NET.html HTTP/1.1″ 302 204 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”
66.249.73.40 - - [09/Dec/2007:07:21:51 +0000] “GET /weird/popup.html/Buy-COM.html HTTP/1.1″ 302 204 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”
66.249.73.40 - - [11/Dec/2007:05:24:19 +0000] “GET /weird/popup.html/Buy-MEUK.html HTTP/1.1″ 302 204 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”
66.249.73.40 - - [14/Dec/2007:17:48:58 +0000] “GET /weird/popup.html/Buy-INFO.html HTTP/1.1″ 302 204 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”

Google has a lust for the goatse! Cannot get enough of it!!!!! Seriously, Google. I just don’t have Goatse on my machine. I promise! Granted, I 302 redirect all 404s to the homepage, instead of 301, so that’s my bad, but seriously - there is a reason I might want to do that and still not have goatse on my site. I don’t ever remember having it anyway. Time to give up the obsession, Google!

66.249.73.40 - - [30/Nov/2007:01:04:10 +0000] “GET /goatse.html HTTP/1.1″ 302 204 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”
66.249.73.40 - - [07/Dec/2007:19:36:57 +0000] “GET /goatse.html HTTP/1.1″ 302 204 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”
66.249.73.40 - - [10/Dec/2007:20:17:00 +0000] “GET /goatse.html HTTP/1.1″ 302 204 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”
66.249.73.40 - - [19/Dec/2007:22:58:31 +0000] “GET /goatse.html HTTP/1.1″ 302 204 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”

More spam anyone? Let’s see here… Google likes Viagra and goatse. I’m seeing a theme here!

66.249.73.40 - - [26/Nov/2007:04:47:00 +0000] “GET /fierce/?ref=SaglikAlani.Com HTTP/1.1″ 304 - “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”

And the trackbacks… oh Google, please figure out what a Trackback is and stop spidering it. I swear, no matter how many bazillion times you look at the trackback pages, you’re still not going to find anything useful there. I double cross my heart and swear to die. This is from Nov 18th-Dec 20th (just over one month):

$ grep 66.249.73.40 error_log |grep -c wp-trackback
938

Think how much bandwidth Google uses that is just completely unnecessary. The countless and senseless bandwidth waste-age. I started using Google because it was light on my personal bandwidth - so much for that idea.