Verzeichnis
terminal23
Checked out "8 rules for creating a passionate work culture." I like these rules, though there needs to be some emphasis added to a few key words here and there to drive home the key items in each point. For instance: "A culture where everyone understands that long hours are sometimes required will work if this sacrifice is recognized and rewarded."
While these "rules" are good, I find that some people/organizations try to artificially implement them without really understanding themselves or the rules. It's like dieters looking for the diet pill or easy magic recipe, rather than putting in the real effort and lifestyle changes that healthy living requires. Whacking your employees to be more innovative or passionate without truly understanding the psychology of it all is not a road to success.
I do take slight (slight!) exception to this rule:
7. Create the space. Years ago, scientists working in laboratories were often in underground bunkers and rarely saw their colleagues; secrecy was prized. In cutting-edge research and academic buildings, architects try to promote as much interaction as possible. They design spaces where people from different disciplines will come together, whether in workspace or in common leisure space. Their reasoning is simple: it is this interaction that helps breed revolutionary ideas. Creative and engineering chat over coffee. HR and marketing bump into one another in the fitness center.I agree with bringing people together, but too many leaders read this and think they need to tear down physical office and cube walls and that will make everything innovative and ideas flow! But that's not going to work with every department or every person. It's a nice idea to give people spaces to collaborate and bump into others, but you're not going to end up celebrating those people who are introverts or who may in fact be more productive in a space they feel comfortable in. Just like "team-building" exercises and get-together social events for an entire company, not everyone is going to be comfortable or have a good time at such things. You'll tell those people who want some space to work rather than be distracted, because they'll have headphones on in their "collaborative pods" and it takes several yells of their name to break them out of their trance (ie interrupt their work). I do have a lot of sympathy to common shared areas that naturally will gather people, for instance break rooms, places to sit/lounge on a break or just a break from the desk to sit and think in maybe a space with some chairs overlooking the morning sunrise, etc. Give people places to broaden out, but keep the places where work can get done in an efficient manner without the distractions or the open space. More importantly, I think the space should foster creativity and underline the idea of trust and being happy when you're at work. People who are happy at work are going to do great things. Some people are happy surrounded by friends, some are happy sitting in an environment where their cube is as comfortable or decked out like their favorite room at home. One shoe doesn't fit all, but you can't certainly be open. Watching videos and photo montages of many of today's prime tech companies, start-ups, and creative shops, I am constantly drawn to their non-traditional work spaces. They're not all open, they're not all wall-filled, but they do have character. If your office space does not have character reflecting the company (or attractive to an employee you're asking to spend their days in), you need to fix that before diving into this rule.
Jeff Snyder has a post up about (Handwritten) Thank You Notes. (note: security recruiter page, in case you're worried about web filters).
I think part of this is not about sending deserved thanks,* but the sort of human contact that really makes our day. Similar to a random (non-creepy) smile from a stranger to someone who goes just slightly out of their way to hold a door or learn your name if you're a regular in a store or location. Or better yet, give us a conscious, sincere compliment about something. I think I remember every time someone has complimented me on my car, or whatnot. We're all people, and it's natural to react positively and memorably to those who poke us the right way.
The article Jeff links to has 5 business etiquette tips, and I can't help but notice that they're of a similar human (humane!) vein. In fact, now that I read to the end of the article, here's the crux: "Will this make someone feel good?" You know, I actually like that as much as the common geek theme, "Don't be a dick." It's a bit of a positive note rather than the absence of negativity, but also doesn't use a word I tend not to use (if you know my full name, you know why!).
* And please don't just send Thank You's like firing off a form letter. Make them personal and try to actually *feel* it. It's sort of like never saying "thanks" or "excuse me" as a rote reflex, but always with conscious sincerity. (You can observe this failure in other people when they say thanks when *they* did something for you...)
Via Emergent Chaos, I got linked over to a nice article on Consumer Reports about FaceBook privacy. Now, being a CR subscriber, I tend to really skip their tech/security/privacy articles because, well, their treatment always makes me nervous or leaves me with more questions than answers (similar to skipping their reviews on laptops/computers, because I build and evaluate my own based on criteria far higher than their focus). But this article about Facebook actually *taught* me a few things that I probably could suspect, but never actually fully appreciated:
Facebook collects more data than you may imagine. For example, did you know that Facebook gets a report every time you visit a site with a Facebook "Like" button, even if you never click the button, are not a Facebook user, or are not logged in?And I like this quote from Zuckerberg, which sort of illustrates that we're often not talking about the same things when we talk about privacy:
...a blog posted last year by founder and CEO Mark Zuckerberg, who wrote, "We do privacy access checks literally tens of billions of times each day to ensure we’re enforcing that only the people you want see your content."That's great to hear about users accessing other users information, but what about the data you use for your purposes and keep for however long?
As kids, we don't listen to the advice of other people. We're too busy being independent thinkers, individuals, rebellious, and caught up in our own autonomous futures. We're also unconsciously sick of being constantly told what to do and molded by parents, institutions, and school.
Part of the process of getting older is appreciating the (value of, which itself is an 'adult' phrase, yeah?) experiences shared by other people, and our learning from mistakes and successes of others. This is probably why adults keep trying to "advise" kids, and we adults just don't get why kids don't listen. I also believe this sharing of experience is one of the best things about the Internet (and maybe one of the worst if you get idiots sharing poor experiences that make no sense or are rife with, well, idiocy).
Anyway, in comes an experience-sharing interview: "MAKE’s Exclusive Interview with Andrew (bunnie) Huang – The End of Chumby, New Adventures." I have a Chumby. While I'd known about the Chumby for years, I didn't actually pull the trigger on purchasing one until last year. Sadly, I jumped on just in time for the wagon to reach the end of the trail: the chumby is on the way out. While it still works, the Chumby is basically dead-thing-uhh-sitting, since its apps rely on the central server for updates and actual function. I see today the forum's aren't working, and my never work again for all I know... (also sadly, I do not have one of the cute, awesome, little bean-bag type plushy ones that I fell for years ago; mine is a hard upright piece of plastic...)
But Huang has plenty of advice to give in this long interview, where he talks about entrepreneurship, design, kickstarter, funding, pricing...
The hardware model is radically different from the software model. Software is innately scalable; you can acquire a hundred thousand users overnight. Monetizing the user base in software is trickier, but most software plays start with scale and then worry about money.This sort of discussion is worth having in really any part of IT. Are you making infrastructure decisions based on what the business wants, or creating a space for the business to find uses for what you do? I'm no expert in this area, but sometimes you need to worry about how your infrastructre or solutions scale and are agile and fill multiple needs quickly, and let the business worry about the monetization, ya know?
In the face of ‘ship or die’, one should not be looking to ship the perfect product. It is more important to ship a product that’s good enough, than a great product that’s late.I think we in security can relate to shipping unfinished products. But hey, that's the name of the game.
But that does show one of the flaws of fact-based reasoning. Engineers love to make decisions based upon available data and high-confidence models of the future. But I think the real visionaries either don’t know enough, or they have the sheer conviction and courage to see past the facts, and cast a long-shot. It’s probably a bit of both. Taking risks also means there’s a bit of luck involved.
Often, a 140-char Twitter post isn't enough to convey a message. In fact, sometimes accessible blog posts don't give enough meat to a discussion that deserves it. This can probably be said about the current discussions on firewall or AV (or more broadly: "old") security technology effectiveness. The bullet points usually aren't good enough to do a topic justice (which sometimes means we're arguing two different nuances of the same position...).
(Aside: I really hate how Google Reader links tack on extra crap behind a URL; which means I have to get rid of it when linking to stuff found via it.)
Anyway, Beau is back to blogging and threw out a post, "Firewalls and Anti-Virus Aren't Dead - Should They Be?" which itself is a response to one from Wendy Nather, "Why We Still Need Firewalls and AV."
(Aside: It might not be proper to call them antivirus tools anymore, but I also still use the term "video" when I mean DVD/Bluray, or to "tape something" as in record it. That's not meant as a dig, though it certainly makes me grin to think of this analogy.)
This is a necessary and healthy discussion to have, even if I am not terribly open to the direction (wet blanket comes to mine). I totally encourage any other bloggers out there to also chime in, because Wendy's closing question is really still unanswered, and it's the Big One, ya know? "So if you don't agree with me, and you've really stopped using these products, I'd love to hear about how you're addressing those classic threats, and what controls you replaced them with."
(Aside: This same feeling exists in the whole Down With Patching movement...)
I really require hard proof that techX isn't working anymore (I already agree it's not as effective, but that's different.). And I also require an alternative (something business/management learns you pretty quick) that matches the technology one-to-one and/or improves upon it. Many vendors think this means making Super Boxes that do so many things with covers on top of covers to shield me from the guts of the surgical tools, and I tend to disagree with that approach.
(Aside: I left a comment on Beau's post, and I'm thrilled to say I only needed one attempt at the captcha to post "anonymously" [or at all]. This is rare, and actually reduces my commenting in outside areas, like the HP evangelist blog which pisses me off to no end each time I try... Of course, InfoSecIsland gets no comments from me because of the login req...)
I do want to bring out just one part of Wendy's post at the end that I liked, "They [users] need to know what each security product will and won't protect, and they need to understand this in a non-technical way..." This is partly why it sucks to talk to security vendors today. Their products are too big and bloated for an elevator pitch that doesn't dive deep into hyperbole. And too complex to understand them well enough to sell them this way. They conflate their protection (DLP is notorious. Also I had a large endpoint security provider today use the words "100% secure" after rolling out their endpoint solution remotely...). And they latch onto compliance and media scares for attention (ok, I do the same thing, since compliance has given me more tools than I'd have without...). The vendors that do this leave a bad taste when dealing with anyone in the whole industry space, which is a shame.
(Aside: Oh, and I think Beau actually agrees with both Wendy and myself [RE: paragraph 8 from his post], it just kinda kneejerk sounds like he doesn't.)
I have a post about BYOD incubating (for weeks), but did want to post my thoughts on this.
Just checked out a Palo Alto Networks sit-down talk today with Nir Zuk (Palo Alto), Rich Mogull (Securosis), and Mark Bouchard (thank you for not making this over my lunch hour!) doing a live-video discussion titled, "Coming to Grips with Consumerization." Of course, I took some notes.
- users want to tailor their damn devices; the perception of mobile devices supports this where users may expect customization with mobile devices where traditional computers have less of this perception. I agree with this for the most part, especially if people are expecting to carry this *and* their own personal devices at the same time. People will want less devices, thus just one that covers both work and personal.
- this mobile issue isn't new. I don't have much to say about this, but once you really sit down, the fundamental issues here really aren't new. Protect data. Manage devices. That was true 10 years ago and is still true today. It's just more difficult today because of how BYOD/consumerization has evolved. This is a good thing to bring up early, since many (even me) get hung up on this being a brand new issue.
is the problem truly just lack of device management? This was a great discussion, and I think this is a huge, huge problem. If not the biggest one: we can't manage these damn devices people want to use for business purposes. Keeping in mind installed apps, blacklisted apps, bad uses/configurations, inappropriate use, etc, as part of this topic.
data assurance is a new key (somewhat). Again, no difference to traditional computers, only now we have less tools to assure this on these new mobile devices. Remote wiping is just not assurance enough.
"make sure bad things don't get into the device," quote from Nir. Kinda sounds like the same problem with any computer for a long time, yeah? Sadly, corporation protections have *less* tools to do this, even as Android/Apple give users better tools to manage their apps and stuff (with arguable oversight). Traditionally, we have device lockdowns, least privs, and endpoint protections. With these new devices, we don't have these tools really at all, or when we do, they're usurped.
some talk about network-based protection/inspection. While I love this idea because it sits squarely in the technical side of things, especially on the network/sec teams, I think it is dangerous to rely on inspection visibility for security in the future. There will continue to be pressure to encrypt and hide traffic in motion. And it's a whole new discussion about how we want privacy but also want visibility; we can quickly talk out both sides of our mouth.
"The reality is that there's a lot of fame in doing one little tiny thing [as a security offense researcher] and somehow being a hero for it. There's not a lot of fame in slogging through the shit, day in, day out, and *not* making the news. And when you're a defender, the goal is to not make the news."Myrcurial, Shmoocon 2012.This quote comes from a great presentation called Doing InfoSec Right from Shmooncon 2012, which itself is chock full of truths. Call me a fanboy, but in my catching up on videos/presos this past month, I've caught several talks including James Arlen, and I gotta say the man rocks. (I was already a Potter fan, so I don't need to declare that.) Doing InfoSec Right Pt 1 and Doing InfoSec Right Pt 2 Here are some bullet points that are whole-evening discussions in themselves: - It's hard to get experience in defense, and the tools lag behind. This topic is important, but it should be prefaced with some role definitions. There is a place for offensive-minded security defenders, but also you should have admins and developers and QA who are admins first but are baking security in (or the service desk guys). These two general roles can easily be separate lives. This came up later as red team guys and blue team guys. - Lack of innovation in defense. While I broadly agree with this, it's hard to agree too much when there are no ideas on what constitutes innovation. *What* should we be innovating? I might even buy that we *don't* need innovation, we just need more emphasis on security and better efficiencies (which modern mega-suite tools fail with). - Lack of sharing in defense / lack of cons and presentations with defense. - We have all these awesome tools, but no one knows how to use them right, nor has the time. - knowledge of analysts vs the knowledge of the tools. This should be a bigger discussion because I could argue either way. We do need bigger tools, but I also believe we need the talent to fill in the cracks and be able to play with the packets when they need to. - The people with heavy experience are the ones who are "above" the roles that are in the trenches. This also feeds into the smarter tools/dumber analysts discussion. - The burning pain behind you. - Offensive side is very good at sharing; defensive is not. - Junkyard Wars analogy for defensive guys: time boundaries and limited things. I think this is an interesting analogy to inject into the above bullet about better tools and using them better and stuff. Or better yet, about having smart tools so we can have dumber analysts. - Forensics vs defense. I just wanted to plop this down, since this is an interesting discussion point that was brought up twice quite briefly. - No evidence of what works or doesn't work. I think there is distance that can be had by injecting the idea that business, IT, and thus security is infinitely varied across all the orgs, businesses, and people out there. This might help explain why our solutions aren't as sexy as attacks against system A, etc. Things like patching may or may not work, but it certainly doesn't work for those who got pwned due to a lack of a patch. It's too late to make that point more succinctly and understandably...
Back in high school I spent some extracurricular time to build a river model as a Biology project. Basically a huge sandbox that could be elevated and have a water pump circulate/recycle water through it to simulate the effects of a river. To me, security is like building that sandbox and planning it all out, but once you turn that water on, it goes damn well wherever it wants to go, taking paths of least resistance using decisions you didn't even know were possible. (Hence the usefulness of the model!)
People do the same thing in business and technology. Security puts down security measures (roadblocks, direction signs, suggestions, speed bumps, rules...), but people that want to do things a certain way will do them that way. The classic example is our current situation of using port 80/443 as universal tunneling ports. Security is blocking ports? Use the one they do open. Ops limits email attachments? Security filters out CC/PII in emailed attachments? Well, use your personal email account. Security/HR has web filtering? Use your smart phone and the guest wireless network to do your personal stuff.
And on, and on. It's not so much a security problem as it is just a path of least resistance problem. Like driving through a parking lot outside the lines and risking not seeing the car to your side, rather than driving within the 'rules.'
Which is funny, since we should also value creativity, outside-the-box thinking, innovation, and doing things new ways. Which is easily at odds with such rules.
This is why I've come to like Hoff's blog name: Rational Survivability. If you/your business continue to survive, that's really the goal, isn't it? Every now and then, I think he knows what he's talking about.
Jack Daniel has a blog post about logging and MSSPs, "Wait, what? Someone has to look at those logs? ". He essentially makes one point that I (and others) have made for years about Managed Security Service Providers:
...in spite of some MSSP’s theoretical threat intelligence and perspective advantages, they simply do not understand the businesses they serve well enough to provide enough value to justify their expense.Looking at an MSSP to do something you don't already do is one thing, but to replace an internal process (or something you *can* do internally) with an MSSP needs to have the risks weighed out. Too often an MSSP is looked at just to save money or just because the internal team isn't perfect (an expectation that is bad to have). An MSSP will have dedicated people with a certain level of expertise and efficiency in monitoring your (and many other client) logs. But... - you're just one of many clients (probably) - they won't know what's really important to you or a throwaway system - they will either require elevated rights into your systems to troubleshoot/assess - or they will be so far removed that they burden your team more than normal with all sorts of pings/tickets on things to look at - the only valid events will be the absolutely most painfully obvious issues; like an IDS or AV screaming about something. But anything subtle or normal-but-bad like a terminated employee VPNing in the day after they were terminated or a local system account in the DMZ suddenly trying to connect internally, is going to be missed in the noise. - they're not going to act on your custom/strange logs And I can pretty much guarantee that the MSSP will raise false positives and will miss true positives. Just like an internal team. But at least an internal team can learn, but business will probably just scream at the MSSP and either leverage SLA/credit or just sever the relationship and start the whole bloody thing over with someone else. One last thing: Having looked at SIEMs/logs for a while now (sort of a part-time duty in my current job), I'm pretty convinced they're best used to improve knowledge of the environment and for supporting operations. But for eventing on security issues? They're only as good as the logs you gather, and the only real benefit is sucking in IDS/AV/mail gateway logs and raising events on those (things that can already raise their own events anyway); a sort of meta-security tool. Or super-custom things you put in, like special filters on your web server logs, or whathaveyou. Still, good luck getting that all to gel properly without full time staff. That said, watching your logs is still one of the best things you can do, but it also must be combined with other things such as regular inventory and various vulnerability/change detection (like new local admin accounts or new AD accounts)....the list is endless on what can be useful.
Got passed this excellent quick article from the Seattle Times, "Buddies have 'awesome' job trying to crack Boeing security". The article talks about 2 of Boeing's security staff (would knowing who they even are be a security problem?) and a bit more broadly about security staff hiring practices in today's digital landscape.
...said last year at a conference that her company's most impressive cybersecurity hires have come from outside of traditional recruiting outlets.
Documentation, videos, and more on how to use Metasploit. And a link to the Metasploit Unleashed tutorial.
An introduction to scapy on the PacketLife.net blog.
Really quick and nice article from pentestmonkey: "Post-Exploitation in Windows: From Local Admin To Domain Admin (efficiently)".
Another old CSOOnline article link I've had sitting around is, "Why security pros fail (and what to do about it)." Per usual, here are bullets points and my reactions. Yes, this starts out juicy and hot.
Problem #1: Security Is Thought of as a Disabler - Yes, a touchy subject. When you talk to your local law enforcement, do you think they give a shit whether they're an enabler or getting in the way of criminals? I'll give a hint: they don't get evaluated on their customer service report cards. Basically, I hate the lie we tell ourselves about being enablers. We *do* get in the way. Deal with it.
That's not to say we should say no and say it proudly and fiercely, and I think the author would ultimately agree with me. We should be involved in business decisions and give guidance as necessary. This is as much an operations or leadership issue as security, though.
This is one place compliance is a good thing: We can point to requirements and use them to say no to things. You want to go to the cloud and that provider doesn't use SSL or other controls to protect data-in-motion? Our requirements say no.
Yes, talking about enabler vs getting in the way is a touchy subject with me. We ultimately need to deal with the fact that security gets in the way by definition. And move on.
Problem #2: Security Offers Only One Solution - I like this bullet point, and it's a great approach. As security people, we need to give the low-down on what a perfect situation may require, including the risks. But we should also give a dose or practicality and realism into our discussion. Yes, we could segment the shit out of the network, but we know that's costly in many ways, but here's what we'd realistically like to see...
Problem #3: Not Enough Humble Pie - Ok, another touchy subject is that of railing against FUD. In a way, railing against FUD *is* FUD, when you really sit down and get philosophical about it. This is another topic we have to accept and move the fuck on about. Yes, some people/vendors do take this to extremes, but please feel free to let them; sometimes we're expecting them to since maybe we didn't know about a particular threat until now. This does underline the need to inject practicality into discussions, though. Sadly, this good bullet point forgot its place and shouldn't have injected the FUD distration.
Problem #4: Believing the Customer Is Clueless - I don't actually get this bullet point at all and it probably requires context on his sources and their experiences and what they're specifically talking about. There are many times where a customer *is* clueless; why else would they bring in outside help? And just because they opt to not listen to certain suggestions, doesn't mean everyone is failing and dumb; just because you told me not to bet on RED for this spin, doesn't mean I am stupid if I do anyway. That's part of the Big Gamble in security.
Problem 5: Personal Cyber Ethics: Are You An Insider Threat? - Not sure I get this bullet point either, and sounds like a source had a personal situation with it. Every insider has ethics temptations. We also should define what security pro is before getting too far into this discussion. Does this include professional consultants or full-disclosure anonymous security "researchers?" I do believe there is a certain level of being above certain restrictions at work, that "normal" users are subjected to. But that is true about any technical or administrative or leadership position. I'm not saying they should be expempt from everything, but this bullet point discussion itself is a bad slippery slope. (A CSO shouldn't have much more access than any other C-level anyway...)
Problem 6: Career Burnout - This is a great problem to bring up, but the handling of it in this bullet is trash. Security is a high stress IT job, to be honest, for a variety of reasons (you'll never win, you always have to educate, you'll never get exactly what you want, you need to be an expert in many things...). No discussion about this should exclude the idea that maybe the career is not for you, if you're feeling excessively burnt out. And figure out and pursue what makes you happy.
Problem 7: Career Perspective Stuck in a Box - I like this item, but part of it doesn't sit well with me. I think we again have to define security pro: are we talking a middle-manager-like policymaker or someone in the trenches? That will dictate a huge difference in making efforts in the 5 preferred skills areas (attitude, relationsip, equipping, leadership, technical). I suppose this is in CSOOnline and thus more about CSOs...in which case, I agree.
It might sound like I have an issue with this article, but I really don't. I like the discussion and bullets, and am just being extra contrarian today.
A 2010 article on CSOOnline goes over, "Penetration tests: 10 tips for a successful program." I've had this in my "to-read" hopper for way too long. The author goes over 10 tips on getting started with penetration testing in your organization.
Penetration Test Tip 1: Define Your Goals - Unlike the author, I think the reality *is* that some goals are just to tick a compliance check box. Nonetheless, this bullet point should also include discussion on managing the expectations of a pentest. Are you looking for a 2-day blitz, a vuln scan, or deep dive into custom application/software testing?
Penetration Test Tip 2: Follow the data - I do agree with this, but sometimes a pentest is more than just focusing on the data, and rather focusing on access. For instance, if I can attack a system and get admin rights, and then domain admin rights, it really doesn't matter where your secret data is. I have access to it. But otherwise, yes, this bullet is valid.
Penetration Test Tip 3: Talk to the Business Owners - Can't really argue with this. Take inventory, get an understanding of software, and align with business, pretty much sums up this bullet with popular buzzphrases. Ok, 2 best practices and a buzzphrase.
Penetration Test Tip 4: Test Against the Risk - When it comes to pentesting, I'm a bit more annoyed when people limit scope based on various factors; in this case data/application value. A development server with no real data is still a risk if I can get into it, drop a keylogger/priv escalation on it, fuck it up enough to get an admin's attention enough to log in, and then scrape their creds/hash. In this bullet, I like how the author basically illustrates my point in bullet #1: you *can* start out with compliance checklist matching, and then expand from there as you truly value the security.
The rest of the bullet points pretty much stand on their own, and are good. I would add somewhere that pen-testing is an iterative process where you go through rounds of testing, adjust as needed, expand scopes, and dig further. Basically your normal OODA loop.
