June 25, 2013
It is that time again when I realized that my daily caffeine intake isn’t done for mere pleasure but out of a need to stave off the ever lurking headache. I started to notice mild headaches in the afternoon that can be immediately alleviated by a nice cappuccino and I had to admit to myself that my body is now reliant on caffeine and will threaten me with headaches unless I give in.
This has happened before in mid 2012 in which missing a day of coffee rendered me almost incapacitated. At that time I decided to detox from caffeine which I did for over 6 months before deciding to partake of the daily ritual again. I missed both the flavor and the routine of it.
And so here I am again deciding that it’s time for another caffeine detox. After mentioning it on Twitter, aside from the responses of my being crazy, several from the infosec community have decided to join me. I’m putting this post together to explain the rules of which I am going to follow and as a guide to whomever else cares to join.
The caffeine detox will begin on Monday July 1, 2013 and I’ve not put an end date. I’ll know when I’m done but let’s say as a measuring stick..once the headaches are gone, the extreme sleepiness has abated, and basically I feel no different off caffeine, then detox is complete. Based on last year’s experience, I’d say 4 weeks should do it. (Took me 2 weeks for the withdrawal symptoms to subside last time). Yeah, yeah, just in time for Vegas. Personally, I’m going to keep going until AT LEAST after Vegas and play it by ear from there.
So here are the rules I’ll be following:
- Going Cold Turkey!
- No beverages that contain caffeine no matter how insignificant (i.e. coffee, tea, decaf, soda, etc). Nothing but water.
- If I ate chocolate, I’d stop ingesting that as well
That’s basically it. Yes, it’s going to suck. But having done it before, it is my way of exerting control and not being a slave to that wonderful substance…caffeine.
See you on the other side.
June 14, 2013
Man! How the tables have turned. I’ve spent the majority of my information security career as a security assessor and consultant. That lavish lifestyle of living out of a suitcase, spending a week or two with a client, agonizing over the executive summary of a report, and then the delivery the final report. With clients, I’d perfected the art of love ‘em and leave ‘em, never staying long enough to see if anything had come from the fruits of my labor. That not knowing is what always left me unsatisfied with being a consultant which is why during my recent job hunt I chose a position that placed me on the other side of the table. It was time I gained the experience of not just telling organizations what they “should/need” to do, but having to actually get an organization to implement my security recommendations. I’ve traded my security consultant hat for a security architect loin cloth & seashell bra.
How was I to know that encrypting sensitive data at rest, prohibiting the use of shared IDs, and the separation of production from non-production environments could erupt into arguments and upper management escalations? I’m beginning to understand the difficulties InfoSec professionals in the trenches face when trying to secure the organization they are responsible for, while at the same time, needing to understand that concessions and compromises need to be made. I’ve had to deal with trying to explain to a business unit why a solution that uses proprietary encryption to “secure” packet captures is not a good idea but then being told upper management is getting it anyway because of the tool’s capabilities. I’ve had to accept why telnet is still needed to log into network devices and that there is no budget this year to replace the offending devices. I’ve had to get used to no longer being the consultant on site that people bent over backwards for. Now I spend my time bent over while trying to dictate why “security is good”.
I’ve been at this new position for several months now and the experience has been eye opening. I never really understood the challenges the security teams faced and often wondered, when doing an assessment, how the hell they didn’t have basic security controls in place. I get it now! One doesn’t just receive a report from a security consultant and the findings/remediation suggestions get magically implemented. That all the security team was missing was some direction and now that they have the report, the fog is lifted; onward and upward Tally-Ho! As a consultant, I’ve had clients say to me, “But we can’t enforce complexity for our passwords” and I’ve replied in the past, “I hear what you are saying, but you are going to have to figure it out.” Right, because getting rid of those legacy applications that are core to the business just so the password can have a “$” in it is going to happen.
What’s my point? (Wait. For. It….) Actually I don’t have a point. I’m just acknowledging the disconnect between my experience as a consultant and now as an on staff security architect. I by no means discount the experience I gained from being a consultant. I’ve gained experience in talking to groups and upper management. I’ve been exposed to various technologies, implementations, solutions and their use cases. But boy, I was not prepared for the myriad of obstacles that impede security teams. With this new job, I’m going to miss the travel and new environments but this is an experience I need to gain if I ever plan on one day becoming an interim CSO. Next…I’ll need to learn how to play corporate politics. :-/
June 18, 2012
Last week included an in-depth twitter discussion about sexism and the phenomenon of booth babes at tech trade shows. The discussion was rehashed on Twitter when AmberBaldet wrote a blog post on why she chose to leave a burlesque show being given at SummerCon. Personally I thought her blog post explained the issue of what’s appropriate perfectly. She didn’t argue about the performers or burlesque shows in general, but their relevance and appropriateness at a conference. So a twitter conversation ensued which I suspect motivated @corum to share his point of view regarding Booth Babes. Again, another article I felt was dead on and from a male’s point of view.
I think the general consensus regarding whether booth babes are appropriate is a resounding, NO, yet vendors still find it necessary to use this strategy. Even amidst complaints by conference attendees & public mocking on social media sites, vendors stick to their marketing guns and bust out the busty femaninas. Now I don’t have a marketing degree or know the first thing about marketing, but I’ve got to assume if the booth babe route is still used then there must be evidence that the strategy works. I mean, why a vendor chooses to purposely offend people unless there was some benefit makes no sense.
So here’s my challenge: I challenge vendors who use booth babes to share their booth babe ROI! I’m not interested in lead generation, because it doesn’t take much effort to scan someone’s badge or get a business card. I want to know, for the amount of money spent on booth babe talent, how much sales revenue is actually generated. Prove to us naysayers, once and for all, that booth babes are a financially sound investment…..a revenue generating investment. I don’t want to hear about the failure of sales when leads don’t translate into revenue. If that’s the case I’d argue you’d be better advised to invest in a better sales team than booth babes. I’d even go so far and challenge vendors to provide an explanation on how using booth babes are more advantageous than staffing booths with knowledgeable engineers.
My argument against booth babes has always been about effectiveness. Does the use of booth babes actually work to sell products or services? I acknowledge the argument that sex sells in certain scenarios (beer & car advertisements) and I am willing to tolerate and concede the use of booth babes if it can be demonstrated that booth babes lead to direct sales. From this standpoint many can then decide to continue to stand on the sidelines and turn their noses up at the practice but may have a harder time arguing against the business side of the equation. Show me that some thought went into the decision. Show me that big ‘ole titties are more effective than an engineer who knows her shit. SHOW ME THE MONEY!
November 15, 2011
As an assessor, I’m tasked with reviewing client’s policies to not only to determine if they are sufficient, but to also evaluate if they are being adhered to. For years, if a policy or procedure was not being followed, I’d assure my clients that exceptions were OK and absolutely expected just as long as they were aware of them. The advice was well received and clients put procedures in place where exceptions were identified, reviewed, and approved…and everyone lived happily ever after, THE END. Naïve, I know.
And so these organizations continued with their exception procedures, year after year, until eventually exceptions became the rule. Month after month, review after review, exceptions became a strategy for departments when they needed to bypass certain security requirements, thus creating a black hole of exceptions never to be seen or heard from again. Eventually, meeting the requirements became the rarity.
Exceptions, much like compensating controls in PCI, were not meant to be permanent. They are usually given when certain processes, practices, applications, or implementations are unable to meet established requirements. The idea is to get the exception so operations can continue, not to get it and forget it. Although organizations have become great at obtaining exceptions, they’ve failed at managing those exceptions. As I am exposed to new and different environments, I’m quite surprised at how common exception black holes have become.
As I mentioned, exceptions are not permanent and should be reevaluated periodically. When an exception is originally requested, it should also include remediation plans for eventually complying with the business requirement. Their periodic review should be an evaluation of the status of the remediation and to determine if other actions need to be taken to mitigate risk.
What I’ve found is by not managing exceptions; organizations have put themselves in a precarious position. Although exceptions are usually reviewed and approved by a central committee/group, the organization doesn’t do a good job of tracking the amount of exceptions they have approved. By not tracking exceptions executives lose perspective on the amount of risk they have actually accepted. After performing an assessment on a few hundred departmental applications at one company, management was shocked to discover that almost 90% of the applications did not comply with policy but instead went through the exception process. This revelation is what most organizations are missing out on. The “exception big picture” is hidden from upper management while maintained in departmental vacuums. Exceptions are not a get out of jail free pass, but are last resorts that still need to be reviewed and managed.
January 11, 2011
This blog’s sole intention was as a sounding board and avenue for venting as I became tired of talking to myself. So imagine my surprise when I was told one of my blog posts was chosen as one of the finalists for the 3rd annual Social Security Blogger Awards. There are 6 categories (Best Corporate Security Blog, Best Security Podcast, Most educational security blog, Most entertaining security blog, and The single best security blog post of the year). Turns out my last post http://topheavysecurity.com/2010/12/13/securitybsides-turned-me-into-an-adult/ is one of the five in The single best security blog post of the year! That particular post wasn’t so much infosec driven as it was overcoming my fears and finding my place in the infosec world.
Voting on all 6 categories is now open http://www.zoomerang.com/Survey/WEB22BQFS9A3BN/ and I really don’t think I’ll snag the title as I’m up against Dan Geer for goodness sake, but the simple fact my post was even nominated, let alone one of the finalists, is a humbling and exciting experience. I’d say 2011 is definitely off to a good start.
December 13, 2010
With the advent of Security BSides and its explosive growth with mini cons cropping up all over the US, and soon the world, many people see the “movement” as innovative and revitalizing local infosec. For me, however, BSides meant personal growth and a commitment to what I now see as my place in the information security community.
In November I was one of the coordinators for a local Security BSides event (BSidesDFW). I’d been to my first BSides (BSidesSF) in 2010 and fell in love with it. I immediately wished that a BSides event would come to Dallas; however the closest one scheduled was in Austin, TX which I was unable to attend. On a whim, Joseph Sokoly (@sokoly) piped up that he would consider a BSides in Dallas which I immediately encouraged and positioned myself as one of the coordinators. As soon as we committed ourselves I was immediately filled with dread and apprehension. I lost sleep for several days and wanted to back out, but once you tell Jack Daniels & Mike Dahn you are going to do something, you better do it.
Now most would think that my apprehension would stem from concern that the event would be a flop but that was the furthest thing from my mind….what I was afraid of, was having to talk to people. Most notably, my fear was centered on having to find sponsors. Growing up, I had a fear of talking to people…ordering from a waiter, asking someone for directions, making appointments over the phone, etc. What was I afraid of? I was afraid of being told, “No”. It was the idea of being rejected that made me hesitant. So imagine what I was going through thinking that I now had to first find, then ask organizations to freely hand over money to an event which is still in its infancy. I WANTED OUT and normally, I would have bailed.
Instead of bailing I decided I was going to “delegate” sponsorship type duties to the other two coordinators. Problem solved as I could work on the behind the scenes logistical aspects while they went out and found the sponsors. Unfortunately, most of the logistics could not be decided upon unless one knew how much money we had in our coffers. Since this is a volunteer based crew we all had our lives to live and the other coordinators were not always able to get the answers I needed as quickly as I needed them. At this point I needed to make a decision….do I keep delegating just because I was afraid to be told no by sponsors or do I let the others do it potentially impacting our timeline and affecting the event? It’s at that moment that I had to put the needs of the event and what it represented ahead of my irrational fears…and I did. And you know what? I was GOOD at it. Once the first sponsor agreed to sponsor BSidesDFW there was no stopping me. I realized that putting on the event become my way of giving back to all those that have helped me either through advice given, critique provided, and acceptance into the fold. An infosec version of pay it forward. Stepping up also helped crystallize a decision I was waffling on which was to re-establish the NAISG Dallas chapter. Again, I was afraid of having to find a venue and find sponsors.
It is now over a month after, what I thought was a successful BSidesDFW, I’m the president of the NAISG Dallas chapter, and I am a happier me. Even though I love my new job, I finally feel as if I’ve found my place in the infosec food chain. As I said in a tweet, “I don’t know everything. I don’t even know half. But I know that I like connecting those that do.”
September 7, 2010
Outsourcing PCI is not a silver bullet
I’m always particularly interested in blogs and articles that seek to help and advise clients on how to achieve PCI compliance. More specifically, I’m interested in articles that give advice on how to make achieving PCI compliance “easy”. After reading several articles I’ve noticed two common suggestions: 1) minimize the scope of the assessment by segmenting the cardholder environment from the corporate network; and 2) outsource as many of the services as possible. I’m noticing more and more of my clients outsource security tasks to 3rd party service providers (SP) in the hopes of being able to successfully avoid having to be responsible for certain PCI requirements. Services such as firewall/router management, IDS, hosting facilities, software development, code review, & software testing are just a few services which clients have outsourced. Some clients think they are being extra slick by outsourcing these services to service providers who have achieved PCI compliance.
In theory, outsourcing does allow an organization to bypass having to themselves adhere to certain PCI requirements but it does not necessarily completely absolve the organization from responsibility. Just because an organization outsources services to a SP the organization is still on the hook for ensuring that the SP is maintaining and managing the devices or service according to the requirements outlined in the PCI-DSS. This may require the organization to dictate to the SP how “things should be done”. This will also undoubtedly lead to the SP having to be included and visited as part of the organization’s PCI compliance assessment. As a QSA, I’ve seen including a SP’s environments in my client’s PCI assessment go horribly wrong.
“Well we were smart. We made sure to go with a PCI compliant service provider.” This is better but the organization is still not out of the woods. One of the most common mistakes I see my clients make is ASSUME that the services they purchased/using was 1) part of the SP’s Report on Compliance (ROC) scope & 2) that ALL of the PCI requirements that pertain to that particular service, are being performed. As a QSA when I am performing a PCI assessment on my client and they’ve outsourced let’s say their firewall management to a “PCI compliant” SP, I need to do two things which coincidently are the same two things my client hopefully did before signing that P.O. The first thing I, and any halfway decent QSA, needs to do is validate that the SP’s ROC scope includes that particular service my client is using. I need to confirm that the firewall management service/solution/practices were covered in the SP’s PCI-DSS assessment. After confirming the first part, I then need to perform a little QSA due diligence, or C-Y-A, and ensure that the ROC addressed the appropriate PCI requirements. Again, I’ve seen how a client’s total faith in their SP’s ROC has led to false promises and broken dreams.
Outsourcing services is NOT a silver bullet in becoming PCI compliant. With it come different responsibilities and potential consequences if not done correctly. Organizations need to establish a more robust vendor management process which includes a lot more than a written agreement declaring the service provider “responsible for securing cardholder data.”
August 13, 2010
Motivation…..Many things act as motivators for how one does their job. Job satisfaction, meeting contractual requirements, or achieving compensation goals are a few reasons why people do their jobs to the best of their ability. Over the past 3 weeks I’ve had conversations where the term C.Y.A. (Cover Your A$$) has been uttered. I have heard this from both clients and from within my own organization which when considered in their context created a light bulb moment for me both as a security assessor working with my clients and as an employee working for an organization that offers security assessment services. When CYA is a critical part of doing your job, the amount of overhead one creates for oneself can be disruptive.
During my career doing both infosec and PCI security assessments, I’ve seen many examples of CYA. Usually when interviewing business units I tend to discover that credit card numbers are being written down, emailed internally, and then stored indefinitely. This typically is both a surprise to my point of contact as it is to me. When asked why, the response is always a whispered, “CYA”. For reasons that may be obvious to other assessors, this response has the hairs on the back of my neck standing. After further discussions, further paper trails, and scope creep, I have realized that CYA is no longer an admirable quality, if it ever was one. Because several business units within organizations tend to follow a CYA course of action, the amount of “sensitive” information that is being shared internally as well as being sent off site expands the scope of the assessment dramatically. And with increased scope comes increased effort to control and bring into compliance these various business units.
Now one might write this off as an organizational and procedural problem, but when I hear the term CYA explained to me internally when dealing with clients, again I was struck with a foreboding feeling. In the name of CYA, the amount of time I am required to spend on each client and corresponding paperwork seems absurd. True I am billable for that extra time, but I now have to fit this into a schedule that was already packed with my “regular” duties.
As an assessor CYA is showing itself to make it increasingly more difficult for organizations to adequately protect sensitive information. At the same time, internal CYA is making assessors more skittish in not only how they handle their clients but in what they are requiring of their clients during assessments. CYA has even recently entered my realm of thinking and has spooked me. Spooked me because of the recent unpleasantness I’ve but some clients through…No, I am not perfect…shocking!! With that said, I’m not naïve in thinking CYA is not in the back of everyone’s mind when doing their job, but CYA should never be the driving factor in the day to day operations for either me or my clients.
July 26, 2010
As a major part of becoming and maintaining PCI compliance, organizations are tasked with performing routine/periodic tasks over the course of a year. And during their annual PCI re-validation, the organization is required to provide evidence that these routine tasks have been performed. But what happens when the QSA determines that the organization did not keep up with their homework? How does it affect their PCI compliance?
Short answer….it doesn’t.
Merchants and service providers (SP) are required to perform the following routine tasks which a QSA then needs to validate as having been completed:
- Daily review of audit logs
- Quarterly internal vulnerability scans
- Quarterly external vulnerability scans
- Quarterly scans w/wireless analyzer
- 6 month review of firewall/router rule sets
- Annual risk assessment
- Annual review/update of infosec policies
- Annual internal penetration test
- Annual external penetration test
- Annual security awareness
- Annual incident response test
Of course if this is an organization’s first attempt at compliance, they will be unable to provide a “year’s” worth of evidence that the above has been completed. But, if this is not their first time around the PCI block, then the organization should be able to provide a year’s worth of evidence. However, what happens when a merchant or SP missed a quarterly scan or it’s been over a year and they have yet to conduct IR testing? One might think that they’ve missed their mark to be compliant for that year, and another year needs to go by. But that is not the case. If an organization failed to meet a task, they are simply asked to promise (and mean it this time) in a strongly worded policy/procedure to have it done in the required timeframe next year. As for the current assessment, the organization just needs to get it done and submitted to the QSA for review, even though it is outside of the task window. As long as it’s done sufficiently, the QSA has no choice but to mark it “In Place.”
What’s the point? I’d like to see a QSA that actually tells the organization, “Nope, you missed the annual window. You’ll have another chance to be PCI compliant next year.” I know I am being harsh but where are the consequences for not taking these tasks seriously knowing they can just get it done after the fact? Does a breach have to occur in which the card brands, jumping up and down, pointing their finger proclaiming that “at the time of the breach, the organization was not PCI compliant.” By then it would be too late. I think most of us can agree that the tasks identified are part of a comprehensive infosec security plan; however, I consider this is just another example as to why the PCI standard itself needs to be re-evaluated on how it is being applied.
July 7, 2010
I know you have reservations about going through an assessment so I propose a mutual commitment of things we can both do to make this process as painless as possible:
You agree to do the following:
- Gather as many of the policies, procedures, and supporting documentation available before I arrive. In other words, if you say you do something, be able to provide some sort of evidence that it is being done.
- Schedule interviews with the people who “do” the actual work, not the managers that think they know what’s happening down in the trenches. I’m sure you think you know what is supposed to occur, but in the interest of not wasting our time, I’d prefer to speak with those that actually do the work.
- Identify your environment. Make sure there is an updated network diagram and a matrix detailing all of the systems that deal with sensitive information. For example, during the assessment is not the time to discover the backup of the production database under the receptionist’s desk, which was replicated “just in case.”
I agree to do the following:
- I will not be your enemy. My goal is not to publicly humiliate you or your staff. The goal is to work together to identify any gaps in your infosec program in order to make it better.
- I will not know everything there is to know. I encourage you to “push back” if you do not agree with anything I say or find. I welcome conversation as it better helps me understand your environment.
- I will not ask “trick questions.” If you want to mislead me, then that is on you. I am going to ask you what I need and want to know.
An assessment can be a learning experience and by agreeing to the terms listed above you can expect the same courtesy in return. As this can help in easing the pain that is….A security assessment.
Disclaimer: I do not speak for all infosec assessors, neither good nor bad. These are my own thoughts based on my own experiences.