I’m pretty sensitive to worker happiness; hey, it’s an INFP thing for the most part. And I liked this article on Gigaom: 5 ways to keep your rockstars happy.

First, some sub-points to mention.

a. “…even-keeled bosses who made time for one-on-one meetings…” – I like 1-on-1 meetings with my boss, if only to make sure I get face time, share my challenges and accomplishments, and just chat a bit. And this is coming from an introvert who hates “chatting.” If I ever move up to mgmt, 1-on-1s will be a staple. It also helps to foster less boss-employee relations and lets people be more formal and at ease with each other. Well, at least that’s always been my boss-employee relationship with strong 1-on-1 comm.

b. “…[help] people puzzle through problems by asking questions, not dictating answers” – How do you best get someone to go what you want? Let them come to the conclusion you want on their own; just guide them. This also allows for better accountability (ownership) and pride and confidence. I also believe this helps foster better innovation, especially if you let them run with an idea that you might not initially think it better. This can be hard for me at times, as I (and I can’t say this without sound like a douche) for most of my life in school and work and personal am usually right in my judgements (see? I can’t say that without being an ass). It’s sometimes difficult to let someone else’s idea be the torch, especially if I don’t immediately believe it’s the best option. But sometimes allowing that helps, especially when a manager is a little further apart from the trenches. I think ultimately puzzling through problems can lead to more acceptance of innovation and even mistakes.

c. “…who took an interest in employees’ lives and careers.” – This isn’t quite as important to me, which isn’t surprising since I keep to myself, am reserved, adore my privacy, and keep some things separated rather well (work vs online persona, e.g.). But I still do like when a boss knows some of my interests and hobbies, and vice versa, and they also have an interest in my career. That 1-on-1 point up above supports this.

So now the real points of the article!

1. Create a culture of education – Agreed, but managers can’t just shove learning down people’s throats. I don’t necessarily want to learn about how department 12 does their job, or take classes on Juniper routers when I’d rather have Cisco classes. Education has to match up with the desires, interests, and goals of each employee. But it needs to be made available and gently guided as well. This should also include actual useful training on technologies available, especially in IT and security. One of my beliefs is that IT ops learns the most when shit hits the fan and we’re in troubleshooting mode. That’s a reactive way to learn, which can be partially fixed with proactive learning and encouragement and value. And truly, the top 10% of your team will be interested in learning. I’m positive there’s a direct relationship there.

2. Provide regular, consistent feedback – Consistent is probably key here. No one likes to have a moving target or a friend (manager) who waffles constantly and flip flops more than a pendulum. The points in the article are excellent, though.

3. Set time aside for weekly 1:1 meetings – Oops, I covered this already. I personally don’t think you can manage people very well and keep them happy without this. Unless you’re a stupid or tyrannical manager that you people don’t actually want to talk to. Then I’d say skip this. 🙂 This also has a security aspect to it, as I strongly believe that the first line of defense against insider attacks and disgruntled employees is the managerial relationship.

4. Manage the grunt work properly – I hadn’t actually thought much on this, but I do like this idea. Managers should also know what tasks employees consider “grunt work,” and manage accordingly. Right now we’re looking to hire a more “juniorish” person on our operations team. This is a great opportunity for each of us to get a “grunt” task off our plates and onto someone less seasoned into their career.

5. Publicly acknowledge good work – Again, as an introvert, this isn’t usually a big deal to me. But it does get noticed when other people are praised and I get left off the list (which happens often when you’re infrastructure ops or security). I do, however, care what my immediate boss thinks of me, just like a parent-child relationship in the early years. And I do understand the more public acknowledgement serves the careers of both me and my manager, so I’ll totally ‘get it.’ If my CEO or other C-level knows my name and can greet me, that alone is a cool feeling, and it helps if there is some public or at least manager-level-back-room acknowledgement going on. For instance, thinking back to high school, some of the best praise and good feelings I got from my teachers was completely indirect, where I would find out that one or two would talk about me in their own circles (for better or worse). That sort of knowledge in their interest means a ton.

This can easily get a bit cheesy however, and I’ve seen awful examples of this in my career. For instance, don’t have a mandatory rotating award; it devalues the spontaneity of it, especially when someone undeserving gets it. When that happens, the entire purpose is destroyed, if not worse. Second, if you have a reward/recognition program internally where employees can send “good jobs” perks to others, don’t go making them mandatory or otherwise so devalued that friends just bounce them back and forth in a you-pat-my-back-I’ll-pat-your-back way. This also somewhat benefits more social people than those reserved introverts that probably only give praise when it truly is heartfelt.

Really diggin’ an article by Drazen Drazic where he goes over 14 things a CSO (read: IT security) can do to make an attacker’s life harder. What’s nice is this list goes beyond the typical (yet effective!) suggestions like just patch systems. In normal fashion, I’ll summarize and react to the bullet points.

1. Avoid password re-use for admins. Duh!

2. Run something that detects new hardware on your network. – Oh my god, absolutely! This isn’t usually as easy to do as it sounds and doesn’t easily fall under the “can-we-buy-a-box-or-tool-turn-it-on-and-it’ll-protect-us-this-way” category that CSOs too often fall into. But the value in this is really phenomenal. Know what’s normal on your network and know when something strange and new pops up.

3. Monitor your internal network to detect weird behavior and unexpected requests. – This bullet point is like a 3-punch combo and should be printed out and taped to walls. I love this: “Your Network Admins…should be allowed and supported with time and resources to monitor logs of the systems they manage.” And this: “Outsourced perimeter management providers don’t care. Their SLA’s claim that they do, but they don’t…” This item also mentions monitoring traffic, which is also invaluable.

I should break here and say two of these items are orgasmically valuable, but they’re also not things that CSOs like. You don’t just buy a box or tool to do it. You don’t just hire more staff (you need staff who know their shit). You don’t just make a project, task someone to scope it out, and then start, progress, and end it with a stamp of success. There’s no end to it. That takes effort to justify to businesses and accounting. Oh wait, that’s basically the point of a CSO. If you want security, you have to spend the manhours and you have to make it an intrinsic cultural goal.

4. Monitor external DNS to detect new website/hostname exposed on Internet by your company. – Whoa, this is new, and I’m not even sure how to interpret this. I think this gets down to knowing what has been published by your domain team to our external DNS and/or what has been exposed by your firewall/perimeter team. You don’t ever want to not know that your dev/test server has had its balls hanging out in the digital breeze of the Internets on accident. For websites, this might be an indication that your web server is hosting sites you didn’t know about, perhaps.

5. Let your System/Network Admins use their magic. – I completely agree that you need to let your talented admins leverage their talent. But there’s a few gotchas. First, not all admins give a rip about security or know jack shit about it or what questions they should be answering. You really need your security folks to also be admin folks, or vice versa. Second, scripting and rolling your own stuff is fine, but that usually has drawbacks such as easy and useful reporting, performance, scalability, feature creep, and limited support outside the people who built the internal tools. Keep in mind that not every system/network admin has the chops (or desire) to dive deep into scripting or even real coding.

I should also break here and say that I still think it is valuable to let talented staff do their thing, even if it means if they leave, their thing is going to go to waste. If you bring in a painter to paint your house, he’ll use his tools and equipment and experience and preferences to do his work. If he leaves halfway into the job, you won’t expect the replacement painter to adopt the exact same project plan, preferences, and tools as your last guy. You let them do the job they do in the way they do it, even if it means starting over.

6. Win small fights – one at a time – Even down-in-the-trenches guys like me need to adhere to this. We can’t get our way on everything, but we do need to make progress whenever we can, so we pick our battles and win the ones we can while noting future challenges we can tackle later.

7. Save the money to hire people with skills instead of getting magic boxes that do little or nothing. – It all comes back to people. Enterprise, especially IT, tends to hate this (or at least be bad at swallowing this pill). At least in my experience.

8. Use open source. – I can agree and disagree with this item, but really the point still gets back to letting staff use their talents, and I agree a talented staffer can probably be more valuable wielding small, more surgical open source tools than unwieldy big-box suites or tools that suck away time and don’t give quite as much value back. Honestly, I think blending tools/appliances from the traditional commercial space along with open source/DIY tools is a solid way to go.

9. Go to real hacking conferences. – Absolutely. This is the “training” security-minded talent yearns for.

10. As a CSO, you MUST be involved with all “critical” projects. – This is a bit political for my taste, but I agree, ultimately. Even from an operations standpoint, it sucks goat balls to be surprised at the final hour of a major project with tasks and requirements you need to meet for their project to work. Security is even lower on that totem pole of information-sharing and inclusion… Ideally, if you run an absolutely tight ship with regards to many of the above bullet points and beyond, I’d almost hope that security is so tight, anything new needs to go through security or at least be noticed by security in quick order. I like to think of security like good ol’ bumper bowling for the kids, where security are the bumper pads placed into the lane gutters that keep the ball rolling toward the pins. If security is tight, people aren’t going to accidentally find themselves throwing gutter balls and upsetting the order of things.

11. Rub shoulders with those in the trenches. – Absolutely, for the most part. I’ve always said if you want to know a company’s security posture, you just have to ask the admins and desktop support persons. They know the score more than any manager or C-level.

12. It takes time. – Yup!

13. Find a blend of talented people for various roles. – I absolutely love this item as well. There really isn’t a security person around who can talk toe-to-toe with the Unix team, the Windows team, the networking team, the virtual team, the web dev team, the software team, the mobile team, and then desktop team at the same time. Assuming the “security guy” can answer every single question is setting him up for failure and loss of credibility. Find the security allies in every team and tap them.

14. Dedicate time to your security technologies. – Just like having talented staff, it can’t be said enough how time investment is important. The article mentions WAF and IDS, and that’s completely true in all cases. You can’t just stand up a WAF and expect it to do magic; you have to get it up, tune it, adjust it, work with devs as they make changes, tighten it up right to the point of breaking shit but not quite breaking it, and then test it, tune it, validate it, etc. That’s not a project, that’s a job.

This is just a personal placeholder to note that Steve Jobs passed away 2 days ago on 10/5/11. The reality has been that, God willing, he was going to pass away before me no matter what (as will many other luminaries from my lifetime, as I get older), but it’s still a sad time to see such a successful influencer no longer with us. Even as I dislike most of the Apple products in principle, there’s no denying the success and vision and inspiration of Steve Jobs.

Just as an illustration of how news travels in this new age, I happened to be playing World of Warcraft at the time, and saw mention in my guild about the event. I windowed out to check CNN.com, saw no updates, so went back into game for a bit, not really sure if that was yet another joke or not. About 15 minutes later, I checked again and saw the actual update on CNN and then noticed my Twitter feed start to light up. I still feel pretty connected, even if I haven’t watched national/local news television spots in 7+ years, don’t read the traditional newspaper, and really don’t listen to local radio but for 15 minutes in the mornings. I’m certainly not a young’in, but at least I’ve got my toes in the technology of today (even if I abhor MySpace Facebook). Granted, if there’s anything I miss, though, it’ll be some local issue…

Via Securosis, I got pointed to an excellent article from an EMC VP talking about vendor beating and some hard lessons in IT. While clearly the point is geared around beating up your vendor for poor reasons and how EMC will work with you, the more powerful points in the article revolve around management of an organization’s IT situation, which includes keeping up with technology, forging relationships, knowing users, keeping the team current, and otherwise just not letting your team be the low group on the totem pole who gets the fingers pointed at them, regardless of reality. Things like the slow creep of poorly planned and poorly grown IT operations. Or the slow obsolescence of systems and even people.

Rob Graham (ErrataSec) has a fun post about Anonymous threats against the NYSE. In it:

The NYSE runs a completely separate network. Well, lots of people say this, like the operators of the power grid, and it’s rarely true. But it’s true in the case of the NYSE: I doubt hackers will find a way from the Internet into the NYSE private network.

But, there are lots of things on the NYSE private network, such as terminals on the desks of traders among the members of the NYSE. If a hacker could get physical access to one of those terminals, he could do a lot of damage.

If that doesn’t scream traditional espionage/infiltration… Which would be quite the interesting attack, and one I’m sure has been on their minds for decades: insiders who either have hacking skills or facilitate access to those who do. Can Anonymous do that? Probably not, but I’d also wonder why they would want to. It’s not like they’ll drive off the fat cats and then sit back and live happily on themselves; such an event would have dramatic effects on their own lives, in not good ways. Then again, that might fit into someone’s anarchist viewpoint…

AndroidPolice (via full-disclosure) have detailed an issue with recent HTC phones (I own one). HTC has new tools that allow for a wide range of logging. These logging features (and resultant logs) are horribly secured, leaving pretty much any app able to harvest this information.

Things like this underscore three small points.

1. There’s been recent hand-wringing about pessimism in security. But it’s things like this, either a priori, or just by being more security-conscious and exposing these things, that really reveals why we are a bit less cheerful. Is it pessimistic just because I know about shoddy code and a vulnerability like this, and likewise would I be more optimistic if I wallowed in ignorance? It’s like not liking strippers as much because you’ve seen them in the back room with their make-up off and holes in their underwear.

2. The lack of initial response from HTC, but then subsequent response and offering of a patch when things go public illustrates the challenge security has, especially when we’re talking things that are so ubiquitous as a cell phone (ok, smartphone) and in use not just in IT circles, but in consumerland. The fact that crap like this even happens is enough to cause an extra drink or two a night. I really believe there are far more people than I’m comfortable with thinking about who will bend and/or break rules and do as little as possible as long as they have a decent chance of not being exposed; part of what I’ll always call the Security Gamble.

3. Why is there this loggingi n the first place? I can only think of three reasonable things. First, compliance with law enforcement initiatives. Second, marketing to gain more information on users and use that for revenue generation. Third, support for when things go wrong, or to improve the product after crashes and such. I firmly believe in the first item, shrug at the second, and sort of doubt the third as being way too proactive for most orgs.

I also think this continues to illustrate why smartphones just can’t last forever and how unmanagable and unscalable they are as technological devices. Keeping up with apps and the underlying security and usefulness and minimizing the frustration is just not going to get better. Sure, they’re smaller (handheld) and it’s easier (cheaper) to buy apps and have them auto-install, but that’s only successful for today because those are improvements over just 2 pieces of the desktop/laptop experience. There is still the quagmire of user garbage that accumulates on these devices that causes just as much frustration with them as any previous computing device.

If anyone has any suggestions on this topic, please comment or tweet or email me!

On page 10 of the PCI DSS v2.0 document, before the actual requirements, there is a section on determining the scope of an assessment, which includes these lines:

The first step of a PCI DSS assessment is to accurately determine the scope of the review. At least annually and prior to the annual assessment, the assessed entity should confirm the accuracy of their PCI DSS scope by identifying all locations and flows of cardholder data and ensuring they are included in the PCI DSS scope. To confirm the accuracy and appropriateness of PCI DSS scope, perform the following:

• The assessed entity identifies and documents the existence of all cardholder data in their environment, to verify that no cardholder data exists outside of the currently defined cardholder data environment (CDE)…

The key word in that whole part is that pesky, “should.” Changing that word would make this an unnumbered unrequirement. In my case, my particular QSA has opted to make this a requirement of the scope, i.e. I need to scan my entire network for stray bits of cardholder data.

Let me say I completely agree with this need. There is everything to gain from a scan like this. And not only should it be necessary, but having the ability to perform a scan like this would mean being able to leverage it for other purposes, like client-specific data, porn (conditionally), or anything else hiding in places it shouldn’t.

But, this isn’t a small deal (windows servers, linux servers, file servers, encoded files, databases, workstations, email servers…), and I don’t actually know of any tools to actually do all of this short of buying into a DLP product whose first phase of implementation probably involves exactly this task: scan everything to see what needs protecting. That’s a heavy pill (full DLP licensing cost) to swallow for just one task (the initial scan). I’m actuall quite amazed that DLP providers aren’t yet offering this as a standalone service/product.

I have stuck my fingers into a few tools, and so far none are satisfactory. Disclaimer: I have only done *extremely* limited testing, and have not even begun to tackle the database aspect.

PANBuster recently hit the blog posts, though everyone regurgitates the same old intro blurbs without any real details. PANBuster is a small non-installed exe file that you can run on the command line of a system and it will scan a target file or path for PAN data. The scan is quicker and more lightweight then other options. But the results haven’t been all that exciting as I find more hits with other tools (both false and potential positives). The biggest drawback, however, is the lack of any UNC or network path support. Extreme bummer. Scripting would probably mean interrogating servers for all physical drives, and remote execing the install file. Really messy.

Spider from Cornell (currently Spider4 aka Spider2008) is a tool that can be installed and run from a local GUI, but can also be command line-driven as well. Executing a scan via the command line is a bit tricky, but certainly can be done. Executing a subsequent scan will not succeed when unattended unless you do some magic (ok, you delete the locally saved scan state file) each time. Configuration can be governed by an XML file, but the values are arcane at best (wtf does option 1048 mean?) and not documented. The fat GUI app also is really actually executed even when done by a command line, and then exits out. Any strangeness and it’ll sit there waiting for an operator to click an “Ok” button.

On the plus side, Spider *can* technically be scripted, and I already have a plan of action to do so with PowerShell. It will save hits to a discrete log (the file names and paths, but not the actual hit data; that can be saved in an encrypted local database). It can also scan UNC paths, including admin shares with the proper permissions. That alone is a huge plus.

On the negative side, scans are long, can include tons of hits, has no scan result management at all, and really doesn’t make me feel very warm. I’d expect a month of execution to scan my network, but I’d have to constantly check it to make sure it’s not hung on something.

SENF is a tool from UTexas and I’ve not tried it out extensively yet. Like Spider, it is made for educational institution purposes where the institution holds system users responsible for the data on them, and thus provides the tools plus instructions so they can scan their own systems and send in reports. SENF is written in Java, which doesn’t excite me, and none of the literature appears to support UNC or network-bound scanning of any type. I’ve not gone far enough to actually try it yet. Examples of use are few and far between, and the tool does not come with predefined reg expressions…

Tools like CardRecon and IdentityFinder are commercial tools, but just fill the same need as the above options: scanning a discrete single machine and/or local drives. I’m not about to install an agent or tool on 500+ workstations and 200+ servers if I don’t have to.

DLP solutions pretty much universally tout their first phase of deployment to be automated discovery of sensitive information that then needs protection. I’ve not seen more than limited demos of DLP solutions, so I can’t comment on them, but the capital outlay for something to fill this need is annoying. Still, I’m close to actually going through the motions to get some ideas on how they solve this issue.

Forensics tools like EnCase can also help in this regard, but are expensive and also not specifically tailored for network scanning; again they’re a bit more suited to discrete system scanning.

Questions to peers have yielded zero actionable answers. The end result so far is my own conclusion that no one is actually scanning their whole network to validate their expected scope, and this need has been unfulfilled.

I’ve been silently stewing musing over Alan Shimel’s recent post about optimism in security (btw, *love* me some Louis CK!). Then I saw Securosis mention it, and I thought I’d echo some thoughts out.

I could rant a lot about this and make a long post, but not only would I add nothing new, I’m sure I’ve said it all here before anyway, and I agree with both Rothman and Shimel above, for the most part.

What I will say, however, is that optimism/pessimism is a relative thing, and it depends on how you define your happiness. Which in turn depends on how you view your current position in relation to your goals. I think way too often security folks don’t think about their happiness and goals consciously enough. They just want perfect security and solutions and get upset (deeply) when it doesn’t happen, or can’t happen. It’s fine to hit that wall and be frustrated, but you have to accept that that is our reality and not let it define your underlying happiness. Strive for more, but be happy with where you are. There are endless cliches on this sentiment, such as stopping to smell the roses, or life’s a journey, etc.

I for one have no problem going to a conference and bitching, sharing war stories, drinking frustrations away, and being generally pessimist. I’d rather do that than pretend everything is shiny and happy and sit back and pat our own backs. That’s fine, but one approach will more probably result in steps forward while the other is really not going to result in progress. I know that might be conflating Shimel’s point about celebrating our victories and being enthused about how far we’ve come in such a short period of technological change.

My own philosophy on happiness (which is sort of influenced by Randian objectivism, though maybe not too obviously from this simplification): Either you’re happy or you’re not. If you’re not happy, change things to attain that happy state. If you’re unable or unwilling to make those changes, then you *must* change your viewpoint such that you become happy. Take for instance a minivan driver. He wants to drive his minivan like a sports car, but it’s just not built for that, so he’s not happy. He has two options: buy a car that suits his wants, or change his viewpoint to become happy with the minivan, i.e. stop driving like it’s something that it’s not, and enjoy it for what it is and the things it does well. The worst outcome is to do nothing and remain unhappy. More people in security (and in general everywhere) really need to put more conscious thought into their fundamental happiness, which goes deeper than point-in-time moments of celebration and joy.

Personally, the angry pessimistic state of security is comforting and actually does make me happy.

As a parting philosophical shot, I will say just be happy with the world around you right now. Enjoy our progress and enjoy nature at every moment you can.

Schuyler Towne has shared a massive 24-part lock picking series on YouTube. Check out the first one, and the rest will auto-play.

Via @Mckeay, I read this SearchSecurity article on the problem between CISSP value and security industry growth. Disclaimer: I’m a CISSP-holder.

“I need to find 2 million people in three years to come close to meeting the expected need,” [(ISC)2’s Executive Director] Tipton said in reference to the information security-related job growth his organization forecasts.

I read that and my first reaction was, “That’s not your problem.” *You* don’t need to *find* these job-fillers. *You* need to just keep certifying *qualified* people to hold your certification. There’s an extremely subtle difference there. A difference that isn’t so subtle once it permeates years of efforts and turns things into, well, this currently watered-down certification where I see very basic questions coming from CISSP-holders as well as just plain lack of knowledge and value from many. I hear, constantly, tales of people getting a CISSP just because they need to for maybe a sales role or something. And it’s simply possible to do that, with a book-based test.

Thankfully McKeay actually essentially echoed my sentiments:

“But the CISSP doesn’t really meet that need because it’s not training per se for any particular discipline,” McKeay added. “It’s simply a way of registering people who have learned enough to pass a test, not necessarily learned enough to do a particular job or even be successful.”

I really think this is a problem where greed is a key factor. Where capitalistic growth is the default goal of a business. If you’re not growing revenues and fattening pockets, then you’re failing. A non-profit (yeah right) like ISC2 should *not* actually be interested in growing numbers on any artificial platform or reason. It should be just fine and dandy with maintaining a status quo of incoming cert-holders. If it *needs* to grow revenues, perhaps look into sanctioned training in security topics (though that might put it in direct competition with places like SANS, which is sort of a good thing). But it’s also not like the CISSP needs to gain credibility. It’s *had* that for years, and it’s not quite understanding how that is going to erode itself (much like Microsoft certs).

From the “we’re too small/it won’t happen to us” file (and via infosecnews) comes this article about a crew of cyber-thieves who would break into business wireless networks or even physical buildings to do some digital mischief and steal money. This article seems well-written, and here are some key points I want to highlight:

The indictment accused the men of “wardriving” — cruising in a vehicle outfitted with a powerful Wi-Fi receiver to detect business wireless networks. They then would hack into the company’s network from outside, cracking the security code and accessing company computers and information.

Another way to say it, random guys wardrive and find random wireless networks to attack. And they do so!

In other cases, they would physically break into the company and install “malware” on a computer designed to “sniff out” passwords and security codes and relay that information back to the thieves.

Physically break into a business, and plant malware or other devices to try to get at juicier loot. That’s a pretty big deal and hard to find if you’re not specifically looking for something like that after a break-in.

It also means you have some decently intelligent criminals who aren’t necessarily doing what usually gets thieves caught: liquidating their loot or associations with other criminals. And they also can be pretty random with their attacks while they wardrive. Intelligent, random criminals with few opportunities to get caught until after the fact, are a typical nightmare for LEO.

As this next blurb says, debit cards and online purchases and things that make our lives convenient also make criminal lives convenient:

“Everything that makes it easy for us to do our business online makes it easy for them to commit crimes online,” Durkan said.

I also like this:

At Wednesday’s news conference, representatives from three of the victim businesses explained how they believed their networks were secure and how quickly the thefts occurred.

I really strongly believe all of the victims were small enough to not have a security role in their business, and likely no security interests other than anything learned in consumerland by employees and default physical security from their leasors.

The only way to fix that is continued proactive education and, unfortunately, examples and lessons from other victims. I’m not about to say they need to create a security role or get an in-house security expert, and maybe not even a high-end pen-test, but rather just pick up a local security expert for some verbal consultatation and some technical chops to do small-time assessments and fixes. That’s really all it takes to keep a business from being the easiest target on the block.

Also, don’t skip over the sidebar in the article, which contains some helpful tips. I’m actually a bit surprised by a few of them, as they’re good! (You can, however, skip over the comments, because they’ll make you feel dumber for having read them.

If you want to get a toe into the world of analyzing malicious PDF files, check out this analysis walkthru, including all the various tools and links therein, for a great look. The PDF format is bounded, and really you just need to understand some javascript to figure out what is going on. Clearly, a little bit of scripting knowledge is useful (in the link above, Python) when doing parsing and deobfuscation. Grab some PDF files, analyst away. Add some Javascript to the PDF files, and check those. Then grab some malicious PDF files, and see how they do what they do.

Now, if you *really* want to know what the resultant code does, you’ll need a bit of Assembly/shellcode knowledge, process debugging, and probably access to vulnerability/exploit resources to see common exploits and leveraged vulns. More than likely, you just need to investigate a PDF enough to get some good strings to search for known malware.

Follow links on that blog plus others in the posts to web your way through various other analyses by various other people.

It’s been a while since I shared my monthly Windows patches write-up that I typically do for work, and I probably should just post them, even though they have a heavy slant towards the server side of things, since that’s what I manage. Ok, so this isn’t verbatim, since I scrub some particulars that apply to my company; specifically I mention our risk to each patch as well as list the actual specific updates that I release because they apply or may some day apply to us. Also, I should add the target audience for this is somewhat technical, but not really other server administrators. More like other IT staff and managers. They’re also largely written for my own notes so I know what is being changed in our environment. I pull all actual updates straight from WSUS syncs.

And for the record, the new look of the Microsoft bulletin pages looks lame. Also, one of the very few months we don’t have any IE patches. Strange.

Further information on patches can be found at isc.sans.org or even eeye.

SEPTEMBER SECURITY UPDATES

MS11-070 Vulnerability in WINS Could Allow Elevation of Privilege (2571621)
An attacker with a valid login could send a specially-crafted WINS packet to a listening WINS server (loopback interface only) and exploit a local escalation of privilege vulnerability. This update fixes that vulnerability, and should be considered critical to install on any servers with WINS listening.

MS11-071 Vulnerability in Windows Components Could Allow Remote Code Execution (2570947)
This update fixes the way Windows may load nearby malicious DLL files (DLL linking vulnerability) when opening .txt, .rtf, or .doc files over a network share or WebDAV connection. This isn’t a big deal from an external attacker perspective since we block SMB and WebDAV traffic from exiting our network, but this type of vulnerability is still very important if not critical to get patched on systems, partly because of the ubiquitous nature of .txt and .doc files in a typical enterprise network, but also the commonly-held assumption that .txt files are “safe.” The details of this vulnerability were made public this past month. It is interesting that this patches core Windows components and not software that typically reads these files, like Microsoft Office, Wordpad, or Notepad.

MS11-072 Vulnerabilities in Microsoft Excel Could Allow Remote Code Execution (2587505)
This update fixes 5 issues with how Microsoft Excel opens specially crafted files. This update should only apply to a handful of servers that have Microsoft Excel or Office components installed.

MS11-073 Vulnerabilities in Microsoft Office Could Allow Remote Code Execution (2587634)
This update fixes 2 issues in Microsoft Office, one that loads nearby DLL files when opening other files (DLL linking vulnerability), and another that deals with how Office opens specially crafted Word files.

MS11-074 Vulnerabilities in Microsoft SharePoint Could Allow Elevation of Privilege (2451858)
This update fixes 5 issues found in Microsoft SharePoint, all generally affecting the web interface and behavior of a SharePoint installation (XSS, script injection, and file disclosure).

MISCELLANEOUS SECURITY UPDATES

DigiNotar fraudulent root certificate revocations
In the past few weeks, a security incident has been discovered with a Dutch Certificate Authority company, DigiNotar, in which malicious hackers were able to get fraudulent SSL certificates issued. These certificates were issued using widely-trusted DigiNotar root certificates. These updates revoke the trust that Windows (and Internet Explorer) had in place for the affected DigiNotar root certificates. Not trusting these certs should have no impact to us, as we have no relationship to DigiNotar or any of their customers. This largely is a client/workstation sort of update, rather than servers, but does still apply.

Via Securosis I followed a link to a detailed article on laptop security. I think everyone should read this article, even if you’re not of a mind to go to these technical lengths to protect your device from an attacker. Props to the author for also mentioning browser-borne attacks, as I feel most common users are far more commonly catching their own trojans and keyloggers during their own use than any attacker trying to put one on physically.

The steps themselves may seem over-the-top (they fall in the scope of the article title!), but I definitely have to stop and think that there are people who have an expensive laptop as their only device, and they have work/personal stuff on there that is worth money to them and maybe to other people. Me, I probably would write off a stolen laptop, take mental inventory of what I have lost data-wise, and assume that the thief is not someone looking to steal my identity or leverage my browsing history to start SEing me. Honestly, the chances of that happening (and happening to me!) is exceedingly slim. Not because I’m impervious, but because the “common laptop thief” here in Iowa is just looking for a computer to use or to liquidate as quickly and safely as possible. They’re not going to whip out the cold boot attack or boot-loaded keylogger. (How come we don’t delve into wallet security quite as extravagently as laptops? Or home security?)

I also have multiple devices, and partly because of the need to use them all, I don’t have my important stuff stored in just one place on an easily-stolen device (ok, that’s arguable, but you have to get into my apartment…).

Some of this position is certainly influenced by my enterprise experience. To a business, writing off a laptop expense is nothing compared to the expense of losing a laptop with client-sensitive information stored in the clear on it. Or the loss of the common local admin username/password. Or VPN credentials. The only scalable solution is to make such device loss a simple hardware cost that a business isn’t even going to blink twice about.

I will say, though, I still like the idea of a protected USB key as a complement to laptop devices. And I’ve long since lost any skill I had at creating and maintaining one. */me marks that down as a rainy day project this fall.*

I have two more thoughts on this whole DigiNotar mess before I hopefully never post about it again.

First, DigiNotar gets breached and trust in their process is broken. We shun them like the lepers they are! Earlier this year, RSA gets breached and trust in their process is (arguably) broken. We wring our hands and wait. The reaction to DigiNotar is not scalable. Sure, it perhaps is the correct approach for various reasons (a- protect yourself, b- give them an economic lesson in the risk of insecurity, c- trust is never “slightly” broken, it’s all broken!…), but it just doesn’t scale to a more important CA or 3rd-party trust provider.

That bothers me. There are lots of innocent victims of DigiNotar who could have done nothing to prevent this issue or better vet DigiNotar. Is that the fault of the people/orgs who shunned DigiNotar, or the fault of DigiNotar? If we, as reasonable security practioners hold fast to the idea that Breach is inevitable, then it’s the fault of the trigger-happy fingers who shunned them, right? Otherwise, why are we placing trust in anything outside our walls at all?

I’m not entirely sure I buy my own arguments yet, but that’d be discussion-for-thought…

Second, I listened to the Cyber Jungle podcast (my first time even hearing about them) specifically to hear the interview of Venafi’s Jeff Hudson who recommends an SSL Certificate breach response plan (keeping in mind his company offers solutions in this space). I was a bit keen to hear what insight someone might have on such a response plan. His plan (min 27:00) takes three general steps/questions (I’m not sure if he’s talking only about SSL certs or more broadly in what he calls your overall 3rd party trust):

1. Who are you using for trust?
2. Where are the certificates?
3. Be ready to replace certificates in response to a problem.

These make sense, but I guess I was already mentally past the first two items and really wanted to hear a strategy for #3. No such luck, and I guess I’m not surprised since that’s really the problem.

At my day job I manage over 100 web sites, most of whom have SSL certificates (to keep this simple). If my CA (Network Solutions) happens to get breached and their roots shunned, in the short term I’m fucked no matter what I do or how much I plan. This is because my domains are hosted by Network Solutions, and I cannot buy a certificate for one of those domains from a different registrar.* I mean, that’s the whole point about making sure certificates are valid! So if tomorrow NetSol is shunned, I have to “quickly” move all my domains elsewhere, and initiate the SSL process. By the way, almost all of my certs are EV SSL certs (yes, I hate them) and they’re not quick to issue, by design. I’d probably have to short-term downgrade them and then field any questions about lack of pretty green colors in the damn address bars.

And that’s just the “simple” 3rd-party trust that is web-borne SSL.

There’s really no BCP/DR plan other than having a pre-existing relationship with another CA that you can migrate to quickly. There’s no high availability, though, and no quick failover. You also need to at least have a few domains/certs on the second provider so that your staff is used to working with them (and they’re used to working with you!), but clearly that increases administrative overhead just a bit.

This gets even worse for those people (not me) who not only use their CA just for domains and certs, but also for their actual hosting. Now there’s a nightmare I don’t want to imagine!

* Strictly speaking, you can do this, but it illustrates and puts further pressure/exposure on a process that is flawed. If I go to an SSL provider and ask them to issue me a cert for a domain hosted by NetSol, their only recourse is to email the publicly listed contact and use that response as the full authorization. This process does not make any reasonable security person feel joyful and has been the source of abuse in the past (we’re talking reliance on automated processes and/or low-on-the-pay-totem-pole customer support).