Just FYI, the CFP deadline for Workshop on the Analysis of System Logs (WASL) 2009 has been extended to next Monday, July 6th.
Is Paris Hilton a slut? This is the age of universal Internet connectivity, web 2.0 or even “web 2.0+”, massive search engines and also atheism: this leads us to believe that “The Truth 2.0” (OMFG!) is undoubtedly possessed by Google. If we can ask Google and then analyze its answer to determine with scientific rigor whether Paris Hilton is a slut, like was done here, why not ask the same source of “Google-given truth” about whether “PCI DSS” is related to “security.” Now, I always hear a lot of high-pitched whining from hardcore security folks that “all those people just want to be compliant, not secure,” and so I wanted to call upon the higher power of Google to figure it out.
So, I ran these queries for “pci compliance” and “pci dss” in Google Insights for Search. Apart from some sexy visuals (no, not of Paris Hilton :-)), the interface shows you other searches related to your original query and also compares their relative volume. Here is what happened:
Search for “PCI DSS”:
Search for “PCI compliance”:
It is interesting to note that Google clearly thinks that “security” is related to “PCI DSS” as top related queries (after the synonym queries “PCI DSS”, “PCI compliance”, “PCI DSS compliance”, etc) are about "security. BTW, the relation algorithm is explained here: the key part is that “Our system [=Google] determines relativity by examining searches that have been conducted by a large group of users preceding the search term you've entered, as well as after.” Moreover, note than nothing else shows up in either list of related queries; pretty much just PCI terms (“visa”, ”credit card”, “requirements”, “dss”) and the word “security.”
Case closed? PCI DSS IS all about security!
BTW, on an unrelated note, did you also know that Paris Hilton qualifies as a platform? Well, you do now.
As we all know, blogs are a bit "stateless" and a lot of good content gets lost since many people, sadly, only pay attention to what they see today. These monthly round-ups is my attempt to remind people of useful content from the past month! If you are “too busy to read the blogs” (eh…cause you spent all your time on Twitter? :-)), at least read these.
So, here is my next monthly "Security Warrior" blog round-up of top 5 popular posts/topics.
See you in July. Also see my annual “Top Posts” (2007, 2008)
P.S. Stand by for the post on Paris Hilton tomorrow… :-)
Possibly related posts / past monthly popular blog round-ups:
Here is a very fun post called “Vulnerability Scanning and Clouds: An Attempt to Move the Dialog On…” I loved it so much, I will just quote my favorite parts here with a few comments. It starts like this:
“Much has been said about public IaaS providers that expressly forbid customers from running network scans against their cloud hosted infrastructure.”
In other words, they host your server, but you cannot check it for vulnerabilities at all.
“As has been noted before, a blanket ban on legitimate scanning activity by customers of their own infrastructure (whether outsourced or not) undermines security assurance processes and can make regulatory compliance impossible; e.g. PCI DSS mandates network vulnerability scanning as a control”
Use PaaS – lose PCI DSS compliance status. Nice! Sadly, the above interpretation is correct as, I suspect, the IaaS/PaaS provider is not allowed to scan your boxes either. So, nobody does. And then you get 0wned.
Next the post highlights that the fact that vulnerability management challenges are magnified by using PaaS/IaaS. For example:
“Scanning may trigger automated or manual actions by the provider. A common automated response from a provider is to apply traffic shaping to slow down the scan, or simply block the client IP address via an ACL update. This can lead to false negatives; i.e. vulnerabilities present are not discovered as the scanner IP was automagically identified as a noisy vulnerability scanner and auto-throttled/blocked.”
He then highlight somewhat obvious, but still key point:
“Even if spinning up copies of “known good/secure” virtual machine (VM), you still need to scan them.”
Further:
“So the bad guys get to scan because they don’t care and yet the customer, who wants to do the “right thing”, is not allowed to. Is that rational?”
The solution is “easy” – if you need scanning (and everybody does!) and you PaaS doesn’t allow it, don’t use that PaaS. But is this a solution? The post the suggests “ScanAuth API” which will allow controlled scanning:
“Something like an “ScanAuth” (Scan Authorize) API call offered by cloud providers that a customer can call with parameters for conveying source IP address(es) that will perform the scanning, and optionally a subset of their Cloud hosted IP addresses, scan start time and/or duration. This request would be signed by the customers API secret/private key as per other privileged API calls.”
I am not sure about you, but this sounds like an awesome idea! The original post calls for the start of discussion, and I am happy to continue it. Finally, as of today, I don’t think we can rely on “other security tools” (software assurance, secure coding, etc) to supplant the need for vulnerability scanning. if you deploy an OS in the cloud, you’d need to scan it.
BTW, similarly to network vulnerability scanning, the situation is actually worse for web app scanning? If you have “doubts” about your blog provider, can you hit it with Qualys WAS?
This WASL 2009 workshop reminded me that I always used to bitch that academic researchers use some antediluvian data set (Lincoln labs 1998 set used in 2008 “security research” makes me want to just curse and kick people in the balls, then laugh, then cry, then cry more…).
However, why are they doing it? Are they stupid? Don’t they realize that testing their “innovative intrusion detection” or “neural network-based log analysis” on such prehistoric data will not render it relevant to today’s threats? And will only ensure ensuing hilarity :-)
Well, maybe the explanation is simpler: there is no public, real-world source of logs that allows comparison between different security research efforts.
Correction! There wasn’t. And now there is!
I hereby acting on my promise to share my collection of real-world logs, mostly collected from systems in the honeynets I ran in 2004-2006. As of now, if you need logs for research, please contact me or get them directly here.
Here is the description of the collection currently shared (more to come!):
Size: 100MB compressed; about 1GB uncompressed
Date collected: 2006
Type: Linux logs /var/log/messages, /var/log/secure, process accounting records /var/log/pacct, other Linux logs, Apache web server logs /var/log/httpd/access_log, /var/log/httpd/error-log, /var/log/httpd/referer-log and /var/log/httpd/audit_log, Sendmail /var/log/mailog, Squid /var/log/squid/access_log, /var/log/squid/store_log, /var/log/squid/cache_log, etc.
License: public; use for whatever you want. Acknowledging the source is nice; Beerware license is even better.
Sanitization: No sanitization or modification was performed. No additional sanitization is required before use for research.
So, for now, if your research requires real-world logs with normal operation data, suspicious data, anomalous data and attack data – grab it here.
UPDATE: I have created a Google Group log-sharing to notify those interested about the shared logs. Please sign up here. The purpose of the group is to notify about new logs shared, discuss the shared logs, collect references to research that uses the logs, post requests for more logs, discuss the events observed in logs, etc.
UPDATE2: the logs are now hosted here, courtesy of one of my readers who prefers to remain anonymous. Thanks A LOT for hosting the logs! Despite the fact that the logs are fully public now, I suggest you still sign up for the Google group as I will announce new log sharing there.
Possibly related posts:
CIS Security Metrics Guide (v. 1.0.0) has been out for a while, I just forgot to announce it here on my blog. The document is definitely a work in progress and the team (myself included) has a lot to do to make it better; some metrics might even change and new ones added. BTW, the project goal was to “develop a balanced combination of unambiguous and logically defensible outcome and practice metrics measuring” and also to “utilize data commonly available in most enterprises.” Since I consider security and information risk management metrics to be one of the most important security challenges, I was very excited to help with this guide.
Here is the list of domains and metrics from the CIS site; it contains a mix of technical (automatable) and non-technical metrics:
“Currently, the consensus group has developed metrics covering the following business functions:
Download the metrics here or direct PDF link. BTW, the Quick Start Guide to launch your metrics program using CIS Security Metrics is coming soon. Also, a global data sharing project based on these metrics may be launched in the future.
Enjoy!
So, “Tomorrows Security Cogs and Levers” by Mark Curphey, by far the best chapter from “Beautiful Security” book (my book review here), is now downloadable in PDF form.
It is hard to decorate this post with a representative quote, but how about this:
“The security tools and technology available to the masses today can only be described as primitive in comparison to electronic gaming, financial investment, or medical research software. […] the information security management programs that are supposed to protect trillions of dollars of assets, keep trade secrets safe from corporate espionage, and hide military plans from the mucky paws of global terrorists are often powered by little more than Rube Goldberg machines (Heath Robinson machines if you are British) fabricated from Excel spreadsheets, Word documents, homegrown scripts, Post-It notes, email systems, notes on the backs of Starbucks cups, and hallway conversations. Is it any wonder we continue to see unprecedented security risk management failures and that most security officers feel they are operating in the dark?”
or
“I was once accused of trivializing the importance of security when I put up a slide at a conference with the text “Security is less important than performance, which is less important than functionality,” followed by a slide with the text “Operational security is a business support function; get over your ego and accept it.””
and
“The areas I’ve pulled together in this chapter—from business process management, number crunching and statistical modeling, visualization, and long-tail technology—provide fertile ground for security management systems in the future that archive today’s best efforts in the annals of history.”
If you are not buying the book, please at least read Mark’s chapter. It exudes pure awesomeness.
Possibly related posts:
It took a while, but here are some fun PCI Q&A from that PCI DSS Prioritized webinar we did a few days ago.
Some questions are way too deep to be answered in a blog post; still, I hope the answers are useful to my readers.
Q: I have a Windows 200X Server and “XYZ Charge” [A.C. - names anonymized] credit card processing software on it; the server is also a domain controller and overall the only server in network, can my network EVER be compliant? PCI DSS speaks of servers not running multiple services such as DNS, Active Directory, etc, on one server. That would mean a small network would need around four servers if they keep cardholder data. What should I do?
A: First, see Myth #6 from the previous webcast. Namely, PCI DSS is not about “compliant networks”; it is about the entire organization. Second, common interpretations of Requirement 2.2.1 do prohibit the use of your DNS server for payment processing. While you might be able to demonstrate compensating controls for other services, combining the actual payment application with public network services is not a good idea.
Q: We have “XYZ DB” as our database and “XYZScan” anti-virus as our security [A.C. - names anonymized]. As a non-profit org. what would be the best route to take to become compliant. Any huge pitfalls to avoid?
A: Obviously, we don’t know your exact situation such as your organization size and the method you use for processing credit cards, it is impossible to give any “authoritative” answer on how to become compliant. However, there is one thing that we can recommend: try not to do ANY card processing “in-house”, but instead outsource as much of it as possible to others who specialize in secure payments. This will limit your exposure to credit card data and thus reduce your risk of BOTH successful hacker attack and PCI non-compliance “assessor attack.” Risks of hosting your own card processing infrastructure are just too high nowadays. As one of my QSA friends once said about card data: “don’t touch that toxic sh*t!”
Q: What systems are in–scope?
A: In brief, systems that “store, process or transmit card data” and those directly connected to them. The PCI DSS document outlines an approach for determining scope; here is an excerpt:
Q: Please help to clarify what “reducing the scope means.” In our scenario we have two main servers that have the databases with credit card information. We are assuming that all computers connected to this network (even through VPN) are required to be PCI DSS compliant. However, would it be acceptable to move these servers to their own network? Does that reduce the scope and what are the most used methods of separating the networks e.g. VLAN, separate firewall segment or zone?
A: “Reducing the scope” means making sure that PCI DSS applies to a smaller part of your organization by limiting where card processing takes place AND by segmenting this part from the rest of the network. The reason for this is that PCI requirements apply to systems that process cards AND the ones connected to them. It is also explained in PCI DSS document. The scope can be reduced by things like:
1. Limiting the number of systems where card data is stored, processed OR even transmitted through
2. Separating such systems from the rest of the network via a firewall, filtering router or something else, described in PCI DSS. Using VLANs for separation seems to be a subject of debate in QSA community; my impression was that it is more often acceptable than not.
In your case, it most likely means moving the card servers to a separate firewall zone and applying the ruleset described in PCI Requirement 1. By the way, why do you have those “databases with card information”? Is there any way to not store the data at all? This will be a perfect example of scope reduction as well.
Q: If I place the database with cardholder data in a separate VLAN or behind a firewall does it reduce the scope? Are the computers outside of that network required to be compliant?
A: If your “database with cardholder data” is separated by the firewall (configured as per PCI DSS Requirement 1!) from the rest of the network, the scope will likely be limited to systems which are in the same firewall zone as the card data database. Computers that are not directly connected to the database due to firewall separation would not be in scope, provided the firewall is configured as per PCI DSS Requirement 1 and thus does indeed separate them. Again, why is there a database with cardholder data? Is there a way to not have such “hacker magnet” database?!
Q: I have heard that some companies require network firewall users to open things on the firewall in order to scan. Why?
A: This stems from the following requirement of “PCI DSS Security Scanning Procedures” [PDF]: “Arrangements must be made to configure the intrusion detection system/intrusion prevention system (IDS/IPS) [A.C. – as well as firewalls] to accept the originating IP address of the ASV. If this is not possible, the scan should be originated in a location that prevents IDS/IPS interference.” While it sounds risky to some, it is NOT “a security crime;” you actually doing this to increase security by letting the scanner assess the vulnerabilities on the exposed systems. It goes without saying that you need to ONLY allows access for the scanner IP addresses and ONLY for a limited time (“scan window”) AND to monitor such network assess, even if you are sure it is coming from your scanning provider.
Q: Is there any specific priority listing for meeting application security (6.3)?
A: “Prioritized Approach for DSS 1.2” document suggests that application security requirements 6.1, 6.2, 6.3 “Develop software applications in accordance with PCI DSS (for example, secure authentication and logging) and based on industry best practices and incorporate information security throughout the software development life cycle.” as well as 6.5 and 6.6 are handled in Phase 3.
Q: Are small businesses subject to the same PCI DSS requirements as large businesses?
A: The requirements are the same for everybody. However, the exact manner in which you accept credit cards does dramatically change the scope of required PCI DSS validation. For example, if you are a “card-not-present (e-commerce or mail/telephone-order) merchant” AND have “all cardholder data functions outsourced” and have overall volume of less than 20,000 transactions/year (Level 4, but depending on the card brand), you only need to answer about 13 question in the Self-Assessment Questionnaire (SAQ). If you process more than 6 million transactions and have your own payment infrastructure, you’d need to pass an actual on-site assessment, covering a broad range of requirements (all 12 requirements with more than 200 sub-requirements)
Q: Where do i get that free PCI eBook you mentioned?
A: “PCI Compliance for Dummies” eBook.
Enjoy! The next webcast will be a lot of fun; watch this blog and your email (if you are on Qualys mailing lists) for announcements.
Possibly related posts:
So, the infamous PCI letter (PDF), an ultimate FunRead (tm) :-), is revealed by Martin. In my analysis below, I hereby promise to remain civilized, even though it would be a trifle too hard at times ;-)
The letter starts on a jarring note, namely, the claim that all merchants “take data security seriously.” This definitely helped me learn a new synonym for the word “ignore” :-) It then follows to mention that despite such HUGE attention to data security, it is hard for them to comply with the PCI standard….
So, item #1 about “incorporating formal review and comment phase on changes to PCI DSS” shows that the writers never looked at “Lifecycle Process for Changes to PCI DSS” (PDF), prominently featured at the PCI Council website. How can one miss it? Beats me. The council document does say that “Changes to the standard follow a defined 24-month lifecycle (!) with five stages, described below. The lifecycle ensures a gradual, phased use of new versions of the standard without invalidating current implementations of PCI DSS or putting any organization out of compliance the moment changes are published.” Specifically, “The second stage allows for market input into evolving PCI DSS through a formal feedback process.” In light of this, I fail to see what the letter writers really mean here.
They also mention ASC X9. Have you ever heard of ASC X9? Yup, my point exactly… The last RSA show had a couple of panels that mentioned X9.111 “X9 Guide to Pentesting,” which probably proves its wide industry adoption.
Item #2 asks for extensions to PCI 1.1 that otherwise “sunsetted” in Dec 2008. I agree that WEP need to be in use for another two years… NOT! Other than that, the differences between 1.1 and 1.2 (detailed here [PDF]) are so minor that needing another year sounds…well… a wee bit disingenuous.
In the next item, #3, they ask for a standard to include “end to end” encryption. Awesomeness ensues ;-) No, really!! It is pretty awesome.
Following that, the item #4 asks for marking “key controls” and for overall “control rationalization.” The former request seems well-served by the recent “Prioritized Approach for DSS 1.2” [PDF], which explains what to do first, second, etc. However, most people agree that more than 224 sub-requirements can use some rationalization. For instance, I am now trying to comb the PCI DSS doc for all the references to vulnerability management; and I am finding that some rationalization would be handy. For example, why does anti-malware belongs in “vulnerability management” theme, and not in “building secure network” theme?
Final #5 firmly treads into bizarre as it rehashes the idea that brands make merchants store card data, while in reality they are begging them to stop doing so (e.g. Visa’s DropTheData site, Mastercard Security Rules, etc)
It ends on a funky note: “today most of the risk and financial burden for operating in compliance with PCI DSS is borne by the merchants.” Funny, they’d mention it, given that most of the financial burden for replacing cards “lost” by the merchants and resulting fraud is borne by the issuing banks.
Here is something else funny: the letter mentions Sarbanes-Oxley act twice as an example of how regulation should be done. No comment here…
In any case, I don’t think this letter is “mostly smoke and mirrors meant to draw attention away from the fact that many merchants don’t want to spend the time and money to become PCI compliant” (as Martin points out), it does contain interesting insight on how many organizations [that we buy from on a daily basis] view data security and regulatory compliance.
There you have it. Thanks to Martin for posting the letter!
UPDATE: PCI Council responds via a podcast at CSO Magazine site.
Possibly related posts:
Here is a perfect weekend post – on SIEM :-) Ok, all this Google web traffic of people searching for “open source SIEM” (sometimes “open source SIM”, almost never “open source SEM” {Is SEM .. dead? :-)}) continues to fill my web server logs and it finally prompted me to write this post, rather than simply whine about, like I was doing for 3 years :-)
It all started here when Matasano folks (sockpuppet.org at the time), in a rare bout of punditry proclaimed back in 2005 (!):
“A Credible Open-Source SIM
I predicted that, just as SourceFire commoditized and co-opted the IDS market, a nascent open source project would challenge SIM products like ArcSight and Cisco MARS.
Result: No Credit [A.C. – this is a later addition to their post when their scored their 2006 predictions]
What’s taking you guys so long? Getting spooked that all the money seems to be going to log management? That’s exactly the dynamic Snort charged in to! Get with the program!”
or in another version posted on DailyDave:
“A Credible Open-Source SIM
There's about $100MM spent annually on products that manage and correlate logs. Guess what? None of it is hard to do. The underlying tools are there. Customers know how to do this better than the vendors do. Expect a mainstream open-source combination of Argus <http://www.qosient.com/argus/> and Sguil <to">to">to">http://sguil.sourceforge.net/>to own the security management conversation next year.”
When I saw it, I got upset that people otherwise so amazingly intelligent (example: Thomas Ptacek) can make claims so incorrect :-) A fun discussion of this prediction emerged in multiple places, also back in 2005-2006: the post comments, DailyDave (Dave’s post, my post, David Bianco post, my next post, the whole thread), my blog (“On Open Source in SIEM and Log Management”, )
Among all the discussion, this piece by Dave stood up:
“My prediction: No credible open source SIM (aka, log aggregator).
Boring work gets done by corporations, and that's that. Not to mention the impossibly high barrier to market of having to purchase and maintain all the random devices that generate logs.”
This is basically the essence of my argument which I also made here in my approaches to log management presentation, slide 10 (even though I was arguing against building one’s homegrown log management or SIEM). To summarize:
There are other related grand problems too, but I digress.
Some people (in the same DD thread) even suggested that the reason that open source community didn’t get to tackle the above problems is simple: SIEM products aren’t really needed (Richard doesn’t have much love for them, for example) and that the community will find some other way of solving it (“a small, useful, standalone tool will almost always be more functional and more reliable than a merit badge feature equivalent in a commercial product”) I agree with that in principle, but if part of SIEM’s value-add is "tying stuff together" then having analysts watching 10 "small, useful, standalone tools" is actually a way back, not forward.
Maybe an open source SIEM project can only support a few “right” log messages? This was a very popular view in the 90s: just filter the logs and see the important ones. But do you know why Marcus created “artificial ignorance”? ‘Cause “filter the logs” approach doesn’t really work: you never know what are the right ones, until you look at all.
What about the existing products, which are
Now, more on OSSIM: Dominic and the crew are awesome, but I think that the above considerations will prevent OSSIM from becoming widely adopted. Here is why: how many open source NIDS do you know? 94% [source: srand() :-)] of folks in security will say: one (Snort), another 3% will say two (Snort, Bro), another 2% will say 3 (Snort, Bro, Prelude), another 1% will say something else. Now, try that with open source SIEM: there is no “snort of SIEM” and the result will be different. IMHO this is inherent (=not a question of time) due to incompatibility of SIEM and open source model, shown in items 1.-5. above.
BTW, somehow recent Twitter SIEM madness (eh… #SIEM madness), caused other people to think about this too.
Conclusions:
BTW, did I mention cloud/SaaS SIEM? Oops, I did now :-)
Have fun with it!
Possibly related posts:
Inspired by the panels we did on PCI (here, here), I decided to start a series of posts with tips on harnessing the amazing motivating power of PCI DSS for meaningful security improvements. These tips are most useful for those in the trenches who are required to comply with PCI DSS while keeping the systems running and secure, but maybe do not know how, and not to those who whine, bitch, blog and now Twitter their way to infamy…
So, got a nice heavy PCI hammer? Where do you hit for security?
Tip #2 will again focus on something very basic, non-controversial and – we are in luck! – spelled out very clearly in PCI DSS: namely, NOT ever storing certain data. This requirement is also one of the key components of Phase 1 of PCI DSS Prioritized approach (detailed here)
By the way, did you know that “data deletion” represents one of the simplest-yet-effective information risk reduction methods ever invented by the humankind? :-)
This is exactly why this requirement is so important: it is much easier to delete the data and organize your business process based on not having it rather than protect and secure such data (and, yes, some will point at this fact and say “Security FAIL!”)
So, what data can never, ever, ever, ever, ever, ever be persistently stored if you are to have any hope of PCI DSS compliance for your organization [to the best of my knowledge, “storage” in RAM is not considered storage]? The answer is easy:
Here is a reference from PCI DSS document:
Remember, if you are persistently storing ANY of the above (full track, CVV2, PIN), you are NOT PCI DSS compliant and CANNOT BE PCI DSS validated [not legitimately, at least!]. Also see Visa famous DropTheData site.
Finally, this tip results in a simple action item:
Enjoy decreased data loss risk, courtesy of PCI DSS :-) Also, please remember that stored of prohibited data killed CardSystems back in 2004 (well, that was one of the things…)
Possibly related posts:
Here is a fun job open at Qualys: Director of Vulnerability Research.
| Description | |
| The Director of Vulnerability Research will be responsible for ensuring that our vulnerability and compliance signatures and detections are kept up to date on the latest technologies. The candidate will also be responsible for advanced research and detection techniques and will interface externally with the security community. Apply and read more. |
Instead of my usual "blogging frenzy" machine gun blast of short posts, I will just combine them into my new blog series "Fun Reading on Security AND Compliance." Here is an issue #16, dated June 11, 2009 (read past ones here).
This edition of dedicated to PCI DSS: stop whining – start securing.
Today’s security reading actually has one topic only: “QSA” lawsuit. It is covered and debated in the following pieces:
Enjoy!
Possibly related posts:
Just reblogging the announcement since I think it would be useful for my readers. These are fun panelists, BTW, not brainless drones (well, I don’t know Brendan personally, but I guess he is not one either :-)) so I suspect the discussion will be worthwhile. And the questions are VERY good too: how does “Is purchasing a SIEM solution a fiscally responsible act given the current state of the economy?” sound? :-)
============================================================
“SIEM Thought Leadership Roundtable" June 17, 2009 2:00PM ET
Mike Rothman - eIQ Networks
Mark Seward - LogLogic
Brendan Hannigan - Q1 Labs
Paul Stamp - RSA
Register Here
https://whitehatworldevents.webex.com/whitehatworldevents/onstage/g.php?t=a&d=667930266
Most IT security departments are swamped. On one hand they’re contending with a highly dynamic threat landscape and an ever-expanding technology portfolio that requires protection. At the same time they’re doing what they can to help fulfill a burgeoning list of audit and regulatory compliance requirements. And on their third hand … if only that were possible! Fortunately, Security Information and Event Management (SIEM) – which has long offered IT Security the prospect of re-gaining control – is possible. In this Thought Leadership Roundtable, we’ll get to the bottom of what makes SIEM different from other security management solutions as well as what level of investment is required to make it work. Questions our panel will address include:
• Is purchasing/implementing a SIEM solution a fiscally responsible act given the current state of the economy and IT security budgets?
• How much of the “compliance problem” does SIEM actually address?
• To what extent do SIEM solutions provide meaningful correlation and enable detection of threats that would otherwise go unnoticed?
• What does the future hold for SIEM, both in terms of functionality and its relationship to other security management solutions?
Not log trust, mind you; this is just a structured dump of how I look at security-related information coming from various public sources.
What are the conclusions one might draw from this?
a. Open bias makes for easier information interpretation than a hidden bias
b. I’d take “biased + knowledgeable” over “fair + ignorant” any day of the week :-)
Enjoy!
If you are into kinky PCI stuff, follow #PCI hashtag on Twitter during today, 6/9/2009 (direct link here)
So today I did the unthinkable – I stopped using Mozilla Firefox for good on all systems. While I’ve rightfully considered the use of Internet Explorer to be “criminal negligence” for a long time, the popular perception of “IE – bad, Firefox – good” seems to have quietly collapsed with nobody noticing … thus, this blog post.
Over few last months, Firefox on several of my Windows systems (please don’t remind me that I should use Linux or that fruit thing) started:
At this point, I am done with it. I am not sure what made Firefox to be the “IE of 2009” – slow, unstable and crash-prone. Was it a modular architecture? Module quality? General codebase bloat? Intense focus on security? :-) I don’t know and at this point, I don’t care. Google Chrome is stable, super-super-fast and renders all the websites I go to well. Bye-bye, Firefox.
Now the question that many would: “But is it secure?” The only honest answer is the same as with Firefox: we don’t know. If Firefox was “secure because it had niche use,” then Chrome is secure for that reason too :-) It definitely has more frequent updates, thus shrinking a half-life of its vulnerabilities. Early on, Chrome had some embarrassing holes, but these seem gone now, with – hopefully! – lessons learned.
However, as I was rereading that ever-awesome Mark’s “Naked Security” preso where he reminds folks that “Functionality > Performance > Security”, the thought that I switched from IE to Firefox and now to Chrome due to functionality (and to some extent performance), not security. I switched to Linux (back then…), because I needed to run a bunch of tools, not because “Linux is more secure.” Then I switched back to Windows for the same reason. Just how desperate a software user needs to be to switch due to insecurity? [BTW, I will explore this subject in the future on KilledBySoftware.info]
Finally, I wanted to finish with with a complete quote from my own post on the previous browser switch, back in 2006:
“So, is security always secondary to functionality? No, that is the wrong question to ask. The truth is that secure functionality is clearly preferred to insecure functionality. However, all the security in the world will NOT make someone switch to something that does not have the needed functionality. Which is, IMHO, an important lesson that we purveyors of security gear should always keep in mind!”
In other words, if something doesn’t work, it might be “secure”, but nobody will use it!
Possibly related posts:
So:
Join Dr. Anton Chuvakin (co-author of PCI Compliance: Understand and Implement Effective PCI DSS Compliance – second edition is coming soon!) and Terry Ramos (co-author of PCI Compliance for Dummies) as they discuss one of the key challenges of PCI DSS: prioritizing organization’s PCI Compliance efforts.
Date: Thursday, June 11, 2009
Time: 2pm ET / 11am PT
Length: 20-30 min plus Q&A
Using the recently released PCI Council “Prioritized Approach” guidance, this 20-min briefing will discuss how organizations can effectively focus their PCI DSS implementation efforts in order to ensure the security of cardholder data, reduce information risk and protect the organization --- all while on the shortest path towards PCI DSS validation. The session will also cover how to use the new guidance to save time and money on compliance projects as well as how decide where to start with PCI DSS.
There will be a Q&A session at the end of the briefing. And just like last time, I’d post the Q&A here on the blog.
Finally, a warning for PCI cognoscenti: this covers basic material; PCI 102, not PCI 600!
Register here NOW!
Possibly related posts:
As we all know, blogs are a bit "stateless" and a lot of good content gets lost since many people, sadly, only pay attention to what they see today. These monthly round-ups is my attempt to remind people of useful content from the past month! If you are “too busy to read the blogs” (eh…cause you spent all your time on twitter? :-)), at least read these.
So, here is my next monthly "Security Warrior" blog round-up of top 5 popular posts/topics.
See you in June. Also see my annual “Top Posts” (2007, 2008)
Note: this is posted by a scheduler; I am away from computers for a few days.
Possibly related posts / past monthly popular blog round-ups:
As I mentioned before, I just had to celebrate the release of this awesome security book “Beautiful Security” from O’Reilly, which I just finished reading.
Now, I will probably have a high opinion of my own chapter (“Beautiful Log Handling”) since it took some work (eh… and one complete rewrite :-)) to create (this why people LOVE O’Reilly books!!) However, I am just about as excited about the rest of the chapters in the book.
Namely:
Overall, this was BY FAR the most insightful and enjoyable security book that I’ve read in a long time!
BTW, authors of this book are not getting paid, but feel free to grab your own copy at Amazon or elsewhere.
Possibly related posts:
Security quote of the day is from here and is related to today's "secure Nation's cyberspace" events:
OK, so this paper ("PCI: Requirements to Action" by Ben Tomhave) deserves a blog entry of its own rather than being buried in a security reading post. It also proves that the claim that nowadays people just won’t read a 38 page paper is just wrong :-)
The fun thing about this paper is that it brilliantly combines the passion of a well-fired rant with a coolness of a detailed procedural document. Read the first 6-7 pages to see a great philosophical discussion on PCI DSS (which is a little too dark at times, to my taste: I just hated that “murky twilight of security management” phrase). Read the rest of the paper and see a lot of useful and actionable guidance on how to think about PCI implementation and even how to do it.
Here is an example of such set of action items from the paper:
Finally, keep in mind that the paper is written solely for large companies (I am guessing L1s and large L2s), but has some ideas useful for smaller ones.
Now enjoy the paper!
If anybody happens to care, I just took this hugely insightful professional development test called "StrengthsFinder 2.0" which is supposed to highlight your strengths from a list of about 40 and also to give you some ideas on developing those strengths.
Perhaps unsurprisingly, here are my top strength results:
Instead of my usual "blogging frenzy" machine gun blast of short posts, I will just combine them into my new blog series "Fun Reading on Security AND Compliance." Here is an issue #15, dated May 22, 2009 (read past ones here).
This edition of dedicated to DRM: “Don't worry about people stealing your idea. If it's original, you will have to ram it down their throats.” (source) :-)
Special PCI DSS section:
Enjoy!
Possibly related posts:
Inspired by the panels we did on PCI (here, here), I decided to start a series of posts with tips on harnessing the amazing motivating power of PCI DSS for meaningful security improvements. Enough ranting; let’s give those PCI skeptics something to whine about!
Let’s start from the obvious. There are a few general ways in which PCI provides value to organizations; such as by creating awareness or motivation for security improvements and data security in particular, helping loosen security budgets (and points at a few things that you probably should have bought even without PCI…), providing a simple laundry list of basic security controls (for those who don’t know what they are) as well as by simplifying [some say too much] “the whole security thing” for those who would otherwise ignore it.
However, this is not what I have in mind here: I’d like to draw my readers’ attention to a few specific things in PCI DSS guidance that will help with security if they are implemented. Also, please keep in mind that your PCI QSA is your final authority on what must be done for PCI, not some random blog on the Internet! :-)
Finally, these tips are most useful for those in the trenches who are required to comply with PCI DSS while keeping the systems running and secure but maybe do not know how, and not to those who whine, bitch, blog and now twitter their way to infamy…
So, got a nice heavy PCI hammer? Where do you hit for security?
Tip #1 will focus on something very basic, non-controversial and – we are in luck! – spelled out very clearly in PCI DSS: namely, passwords.
PCI DSS has a few areas where the use of passwords for cardholder data security is discussed:
Requirement 2 covers the following: “2.1 Always change vendor-supplied defaults before installing a system on the network—for example, include passwords, simple network management protocol (SNMP) community strings, and elimination of unnecessary accounts.”
This simply means make sure that if you buy “a piece of IT” which has a default password, it is changed right before said piece of technology is connected to a production network. Simple, obvious [for those doing security for more than a few minutes :-)] and useful, since password guessing and default account trawling are still common ways to break into networks. BTW, I said “a piece of IT” and not “a computer”, since it applies to various devices (routers, switches, wireless gateways, etc) as well.
Requirement 8 covers the following:
“8.4 Render all passwords unreadable during transmission and storage on all system components using strong cryptography.”
This simple means that passwords should never travel across the network in clear text (such as in FTP and – gasp! – telnet). BTW, for every one time that somebody says that “nobody is using telnet anymore”, I can point at a box that has telnet enabled (yes, this is 2009, not 1989!)
Same requirement also has the following guidance:
“8.5.3 Set first-time passwords to a unique value for each user and change immediately after the first use.”
“8.5.7 Communicate password procedures and policies to all users who have access to cardholder data.“
“8.5.8 Do not use group, shared, or generic accounts and passwords.”
“8.5.9 Change user passwords at least every 90 days.”
“8.5.10 Require a minimum password length of at least seven characters.”
“8.5.11 Use passwords containing both numeric and alphabetic characters.”
“8.5.12 Do not allow an individual to submit a new password that is the same as any of the last four passwords he or she has used.”
This simply means that passwords should be kept secret, hard to guess, hard to break, changed frequently-enough-but-not-too-frequently, and not reused – and that all the above stuff should be known to everybody who can change his/her own password and who can touch card data.
Some automated tools can scan your systems and automatically verify that such configuration settings are in use across many systems.
BTW, if you read this and thought “huh? there is nothing here that I didn’t know before,” I have a secret to tell you: this was NOT written for you; this was written for somebody who runs the site where you just bought that new iPhone and who now has your credit card data…
This is my first post since coming back from vacation; as you can guess, I’ve been busy with work and not with blogging. Still, I just have to celebrate the release of this awesome security book “Beautiful Security” from O’Reilly. I just received my author copies and can’t wait to start reading the other chapters.
Now, I will probably have a high opinion of my own chapter (“Beautiful Log Handling”) since it took some work (eh… and one complete rewrite :-)) to create (this why people LOVE O’Reilly books!!) However, I am just about as excited about the rest of the chapters in the book. Namely:
BTW, authors of this book are not getting paid, but feel free to grab your own copy at Amazon or elsewhere :-)
It took a while, but here is some fun Q&A from that PCI DSS Myths and Misconceptions webinar we did a few moths ago.
Some questions are way too deep to be answered in a blog post; still, I hope the answers are useful to my readers.
Q: What about the organization that says "but we use authorize.net, PayPal, Google Checkout (or whoever) to process our card payments for items we sell on the web. We don't ever handle the card data ourselves, so we don't need to worry about PCI...do we?"
A: Indeed, outsourcing credit card data processing is a very good way of reducing the scope of your PCI compliant environment. However , it is not the same as “outsourcing PCI DSS” since it does not completely shield you from PCI DSS requirements. “Scope reduction” is NOT “PCI elimination.” There are still areas where you must make an effort to comply. However, PCI Qualified Security Assessor (QSA) is the authorized source of this information.
Q: What is the purpose of the Self Assessment Questionnaire and why do we need to complete one for each scan? Our credit card processing company requires us to complete a Self Assessment Questionnaire to accompany each scan.
A: SAQ purpose is to assess (well, “self-assess”) security posture of an organization, just as the name says. The SAQ is a way to review the security controls which are in place without the help of an auditor. There is no formal requirement to complete a self-assessment questionnaire after every quarterly scan. Scans must be performed once a quarter, while a self-assessment questionnaire must be completed once every year. However, your acquirer might have a different opinion and might prefers to collect more information about you on a more frequent basis. BTW, you are supposed to answer the SAQ honestly, to the best of your knowledge, and remediate the gaps found.
Q: Is a QSA the only authorized entity to run a scan or can I as the owner of our business run the scan myself?
A: This is a pure misconception; 100% false. As per PCI DSS requirement 11.2, an approved scanning vendor (PCI ASV vendor) must be used for external (=Internet-visible) scanning. Internal scanning can be performed by yourself or anybody else skilled in using a vulnerability scanner.
Q: Do we need to ensure that our third party fulfillment company is PCI DSS compliant as well (especially if they are taking credit card numbers for our customers)?
A: It is hard to say how the contracts are written in such case, but often the answer is indeed “yes.” Moreover, if they take credit cards they need to be compliant and protect the data regardless of their relationship with you. PCI QSA is the authorized source of this information.
Q: Is this [PCI] a US requirement only or do we need to ensure that our international offices are in compliance as well?
A: PCI DSS is most definitely not just US; it is a worldwide mandate by the global card brands: Visa, Mastercard, American Express, Diners Club, etc.
Q: I thought using PA-DSS application makes me PCI compliant, isn't that the purpose of the PA DSS?'
A: Not, it most certainly does NOT. PCI DSS and PA DSS are separate mandates; one applies to organizations, networks, systems [PCI DSS] while another [PA DSS] applies to payment applications only. This is actually a very common misconception. Using PA DSS-certified application certainly does not make you PCI DSS compliant!
Q: Is a fax with credit card information that arrives to organization’s fax server considered to be a digital copy of this data?
A: A digital fax containing a credit card number is likely in scope for PCI DSS. There is some debate about the “pre-authorization data”, but protecting credit card information applies to all types of information: print, files, databases, fax, email, logs, etc.
Q: What if this fax contains a CVV2?
A: In this case it cannot be stored and must be destroyed. I’d leave the debate about the temporary storage of CVV2 containing media to PCI QSAs and lawyers. PCI DSS states that you cannot store certain types of credit card data, such as CAV2/CVC2/CVV2/CID. Overall, you should also minimize all storage of card data; and this is exactly what card brands recommend (e.g. see Visa’s DropTheData site)
Q: What are the most common ways to steal data from merchants?
A: It is very hard to summarize as reliable statistics are not publicly available. Informally, SQL injection has been a very frequent route to steal such data and so did lack of data encryption on internal networks.
Q: What are the real costs of being not compliant?
A: The reliable cost estimates are not available in the public domain. Overall, the costs are not just in monetary fines, but also in lawsuits, breach disclosure costs, investigation costs, processing rate increases, contractual breach costs, cost of additional security measures, cost of credit monitoring as well as a cost to have a QSA assessment performed (if jacked up to Merchant Level 1 due to a breach)
Q: Is there some type of official timeframe that everyone needs to be compliant?
A: Official PCI DSS compliance deadlines have already passed back in 2006 and 2007. However, card brands such as Visa recently typically set their own dates (example from Visa).
Q: Just to summarize, PCI is about processes and how these processes filter to how actions, processes, security both physical and procedures/audits and networks are setup and managed?
A: That is correct. PCI DSS goes beyond information technology and covers, for example, paper records as well as other ways of storing credit card information. However, your PCI QSA is the authorized source of the information of what PCI should cover in your organization.
Q: What criterion do the ASV follow for the external PCI DSS scanning?
A: Brief answer here. Longer answer is here.
Q: If the deadline for compliance has past, what might be a more relevant question would be when will merchants be completely liable?
A: This is a very dangerous way to think about PCI DSS. This highlights the fact that the person asking the question is only thinking of PCI DSS because of penalties and not because of the requirements to protect credit card data. Please focus on securing the card data, not on “avoiding liability.” Here is some useful reading on the subject.
Q: For a small merchant that only processes a handful of transactions a month, are there alternatives to some of the expensive technology requirements (e.g. application firewalls, independent web/db servers, etc)?
A: Outsourcing credit card transactions is likely the right answer in such circumstances.
Q: Is PCI just a way to avoid paying heavy fines in case of fraud?
A: PCI DSS compliant status will likely not protect you from fines and other costs in case of a data theft. Ultimately, you must protect the data and not just be compliant. If you're compliant, but not secure, and then compromised and fraud is committed, your will probably be liable for losses.
Q: Does PCI only apply to digital data, what about credit card information on print outs?
A: PCI requirements do cover printed data as well. See example in PCI DSS guidance itself.
Finally, thanks again for attending the webcast!
Note: this is posted by a scheduler; I am away from computers for a few days.
Instead of my usual "blogging frenzy" machine gun blast of short posts, I will just combine them into my new blog series "Fun Reading on Security AND Compliance." Here is an issue #14, dated May 1th, 2009 (read past ones here). I admit that some stuff has been sitting in my “2blog queue” for way too long, but you know what? If it is relevant after a few weeks of “cooling down,” it is even more worth reading :-) This time I have to clean up a HUGE 2blog backlog :-(
This edition of “Fun Reading on Security and Compliance” is dedicated to all those who only read blogs posts after they’ve been twittered :-(
Special PCI DSS section:
Enjoy!
P.S. The word “fun” has been used 17 times in the above text :-)
P.P.S Now I’ve done it. I cleaned my “2blog” folder.
Note: this is posted by a scheduler; I am away from computers for a few days.
All other “security reading” issues.
