Star Trek’s Kobayashi Maru; a starship captain is given an unwinnable exercise during academy training, but protagonist James T. Kirk cheats and beats the system through outside-the-box thinking. In the paper, Embracing the Kobayashi Maru: Why You Should Teach Your Students to Cheat (pdf), Greg Conti describes the ways students cheat on an exam, and why this lessons matters.

We’ve always been taught to color inside the lines, stick to the rules, and never ever cheat, but in seeking cybersecurity, we must drop that mindset. It’s difficult to defeat a creative and determined adversary who must find only a single flaw among myriad defensive measures to be successful. We must not tie our hands — and our intellects — at the same time. If we truly wish to create the best possible information security professionals, being able to think like an adversary is an essential skill.

Just read an article from SmartBrief: Learn-gevity: Enhancing your ability to learn, perform and succeed over time. Not sure I would have normally read this article, but it came across with this hook:

“The half-life of technical skills continues to shrink. According to Josh Bersin, the half-life of a technical skill is just 2 years.”

I mostly agree with this. I’ve been in IT for 15 years. Even something as large as an OS change is a problem for us. I knew Windows 2000 and XP really well, and thankfully the latter hung on for quite some time. But these days, my XP knowledge doesn’t serve me much at all; everything is moved around in modern OS. I remember when we installed our first Windows Server 2012 box and half of us couldn’t figure out how to log out of the damn initial interface! This remains true for other topics such as how we manage things (devops!) and location (cloud!). I think 2 years half-life for IT skills is really liberal, though. I’d push that to 3-4 years, with how most companies operate.

That aside, I love the points about learning. It’s not just about learning, but having a proper mindsight for the rest of my career. I especially take to heart a few of the points the author makes: stop think about being an expert, be inquisitive, stay social, set personal habits around learning.

But I would add one point of my own: Embrace failure. One thing I’ve learned from my previous job experience is to be risk-averse. But that hurts, and I struggle with that on a weekly basis. I want to learn things and get better, but we get better with practice, and not all practice yields success. We have to make mistakes, we have to fall down, we have to get errors and miss things. Doing this on the job is stressful for others, but this needs to be part of the process for learning. It’s part of the scientific process, and it’s part of growing. It’s easy to fail on your own time and get better. But it needs to at least not be overbearingly suppressed in the workplace as well.

You can’t be on social media in security without hearing about the “cybersecurity talent shortages.” I really like Michael Santarcangelo’s CSO article: Are new security specialists starting at a disadvantage?

“Nowadays, most junior security professionals come right out of college with a baseline security foundation as they enter the workforce – but lack that foundational and practitioner knowledge of the networking side of things. This trend is causing real-world challenges for security operations center (SOC) teams.”

True! And while it’s good advice to recommend looking at candidates from other areas of IT, the problem becomes one of pay when that security job is a slight step down in terms of pay for a candidate that is “new” to security, but established in their IT field. This is one of several problems swirling around our state of hiring and talent today. (For example, the IT boom of 1999-2000 producing many new IT practitioners, but now cloud services and general 15+ year boredom are fueling experimentation into security, but security isn’t ready to support them.)

Attackers can do so much in memory these days and not touch the disk, especially with things like PowerShell to abuse. In walks a talk to help combat that: Taking Hunting to the Next Level Hunting in Memory by Jared Atkinson and Joe Desimone. And the code released to do it: Get-InjectedThread.ps1. Talk was also given in May at SANS Threat Hunting and Incident Response Summit 2017, and while I don’t have a video link for it, the PDF of the slides is available. If some of this sounds familiar, one of the presenters is from Endgame which is where I recently linked another similar blog post from.

I’ve recently started looking into getting casually involved in CTF competitions in the infosec space. And a common question I hear is: What’s the point of doing them? Often these competitions have almost trivia-like questions that involve knowledge, some meatspace social engineering or lock picking, radio manipulation, pcap analysis, malware analysis, image analysis, decoding/decryption, reverse engineering, network service fuzzing, and so on. Sometimes, you either know it or you don’t, and if you learn it on the fly, you’ve eaten up your time to do the rest.

Well, the answer isn’t a direct one. Do you learn key infosec skills? Probably not directly.

But you do learn how to do things you sort of already know faster and better. Like knowing a bit of Python and then banging out a few snippets for some challenges. +2 to Python skill!

You also pick up the ability to do cheap, quick little things like that you can emulate in the day-job to analyze (quickly) some new exploit code that is released, or troubleshoot something quickly at work, or manipulate and fuzz a new app for a project.

It’s about practice, and in a sort of intense time-bound moment.

It’s about exposure to a few new concepts and skills that can be picked up.

It’s about meeting others and sharing some notes to get better and pick up those new skills easier.

But, if I had to just give one answer, it’s the common answer for those that desire to be an expert in something: practice, practice, practice.

BHIS has a build post for an updated hashcat password cracking workhorse system. Pretty cool! It almost makes me sad to think about building a system and not use it for gaming, but it certainly makes sense if you need to crack hashes on a very regular basis. For less needy setups, the main goal is Ubuntu 16.04 + NVidia + Hashcat appearing to all work together with no fuss at all. From there, just slap together what you can afford or need or fit into your space, casewise. For me, I’ve built gaming systems for almost 15 years, all with water cooling, so I would continue to make that a necessary build piece for the quieter operation. Though, to be honest, GPU fans these days (that I’ve heard) are surprisingly quiet when new. And the all-in-one CPU cooling loops are super convenient.

Any time I’m building a system, I honestly still spend some months researching on the HardOCP forums. Been a member for so long, and it’s still a great community to ask questions of.

Not much to say about it yet, but this is the OWASP Testing Guide v4. I’ve just not marked this yet, so wanted to get it put in here for future reference. I’ll likely add a link on the side when I do an update.

Every day, there are posts on infosec social media about getting into the field. And every day there are replies with a variety of answers. It’s a pretty hot topic, and has been for a long time, though probably fueled a little bit more than usual this year due to Mr. Robot and recent job reports about a void in infosec candidates. It’s probably also impacted by the feeling that, “I don’t know enough to be in security, these guys are pros!” and the subsequent perceived need to learn more.

I penned this yesterday to link to a blog post attempting to be a source to point such questions to, but scrapped it thinking it wasn’t useful enough. Today, I see the author has extended the list to be far more interesting and broad! And make no mistake; this is a hard question to answer, since every role is a little different and we all bring various bodies of knowledge and experience into the field from where we’ve tread previous; some new to linux, some new to windows, and so on.

Is the list perfect? Of course not, but it offers lots and lots of ideas for someone with questions about how to get a foot into the industry.

News about the disclosure of RNC files is everywhere this week. But I just want to point to a comment thread about the topic over on Reddit. News like this is very watered down, usually, and we don’t get proper context due to lack of back-and-forth. Though, to be fair, UpGuard’s write-up is pretty thorough!

What’s the bottom-line deal? Data that should have been private was placed onto Amazon’s S3 cloud platform, and then made public without proper access control in place. Someone found it. Game over.

Mistakes (and it likely is just a mistake) like this are made all the time, but they usually get made behind the curtain of a private network. None of us hear about them, and they likely don’t get abused, or if they do, it’s found and fixed silently. But those mistakes made on the public cloud platforms becomes a very big deal. Get smurt about cloud security! Companies cannot treat data in the cloud with the same lack of care that they do with internal privileges and access.

I saw a talk the other week about Software Defined Radios and how they work, plus how to get into the hobby. One thing I felt was just minorly missing was some context on how useful SDR may be. Just today, I saw a link on Reddit to another Intro to SDR and RF Signal Analysis. Since seeing the previous talk, I can actually begin to digest this information, but more interesting are the real world applications near the lower half of this post.

Looking for a Discord community? I ran across The Penetration Testing Community the other day and joined up. I cannot attest to how useful the community is yet, but they’re white hat oriented and already have plenty of participation. Seems interesting, since I usually have Discord up somewhere, just like I always have IRC up at home. (This reminds me, I haven’t had an IM program up at home in…several years…this makes me feel old and makes me sad…) Like most (all?) infosec communities, this one is a bit beginner/student-heavy in population. If you join, be sure to read the rules, as they do require you to announce yourself, though I don’t think there is any effort made to validate what you say.

Quick read of the day: Enterprise Offense: IT Operations [Part 1] – Post-Exploitation of Puppet and Ansible Servers. While not quite on the scale of pwning a full domain with AD, pwning the system that is allowed to make configuration changes at root level on many other systems is still a juicy target.

Cybersecurity spend: ROI Is the wrong metric. I normally don’t bother with some of the major publications and their news and article feeds, but this one caught my eye and I enjoyed the message being presented, even though it still falls into the same traps as other articles from these publications: they sound important, but really don’t say anything concrete or immediately actionable. Still, it’s almost there for lines like this:

How do you want your network defenders to spend their valuable time? What do you want them to accomplish? What is the 140-character Twitter line that describes the essence of that effort?

Doing some random morning news browsing, and I followed a link to “10 things you need to know before hiring penetration testers.” I love lists! I love good ones, because they’re good, and bad ones, because you can rip them up and point out good things by using the bad examples. They’re just really easy to digest. Like sushi. Anyway, so what are the tips you need to know before hiring and are they good tips? (Turns out they are!)

1. Strong Communication Skills. Ok, this article starts out strong by repeatedly mentioning something I hold very dear and consider myself to be very strong about: being able to adjust communication between deeply technical and far less technical for those not so inclined. I also really like the mention that technical skills can be taught, but communication skills are far harder. I think the one exception to this rule would be those people who are very reserved and quiet before either breaking out of their social shell or gaining that confidence and voice in what they’re saying. Some people just need past that imposter syndrome feeling, and they’re off to the races.

2. Beware of “Secret Sauce” Consultants. I didn’t understand this item from the title, but really this is talking about making sure findings are repeatable as described and accurate, and partly to know what you’re talking about for a pen testing methodology. I wish this item was longer and more expounded on, though.

3. Get Involved with the Security Community. Keep in mind this article is about things someone needs to know before hiring a pen tester, so this item is asking the hiring manager to get involved with the security community and go where the experts are. There’s not much to say about this. I’ve had managers who are technically involved and others who really just don’t know anything about the greater IT community outside the company. While both can be effective, one tends to be better tuned than the other.

4. Reputation is Everything. A really strange bullet point, but packed with very valid points. The exception, of course, will be entry level people who really do come out of nowhere, but I agree with the points that a pen tester should be known to some degree or other. They don’t have to necessarily be a keynote speaker, but participating and being involved to whatever degree and demonstrating some continued learning and passion should certainly be a factor. I really do like the parting comments about bewaring of egos and rock stars. There can be a certain level of “clubbyness” to a certain half-technical level of known speakers and infosec pundits who get really big egos and many followers/fans, but who are really only just complaining about the same things everyone else is and not offering much new other than stroking the ego.

5. Technical Acumen: Required. This seems obvious. Pen testing is not a task you can just talk your way through. Yes, you can fake it pretty well, since no one hiring you may be smart enough to call the BS (“Sorry, I couldn’t find anything wrong…”), but ultimately that will always get found out, and we start talking about the previous point about reputation. This ends up being a really good bullet point about results and understanding tools, rather than just blindly wielding automated suites.

6. Well-Rounded, Recent Experience. This is a touchy subject lately. If every pen testing position required experience, we’d never get new ones. I get the points about needing experience; I actually agree that the typical pen tester should not be fresh out of high school or probably even university. But there are exceptions and there certainly are positions next to full pen testers that entry level persons can fill. This article appeared in 2014, and today there are many more opportunities to at least practice and demonstrate and build skills in pen testing activities. But the point is still really strong. To me, pen testing really should require plenty of real world experience in, at least, IT in general.

7. Hire Passionate Hackers. Maybe my favorite bullet points on here. I’ve done some participation in interviews for fellow IT admins in the past, and I always look for what I call the “geek side” of candidates; do you geek out about this stuff at home as well as work? And so on. I know that can lead to burn out, but I find it important to be passionate and enjoy this work, and to demonstrate that and be around others with similar passion. And I echo the quote in here; I love the challenge and solving puzzles and learning, but it’s very much about helping others be more secure and make them better, whether that be fixing technical holes or educating on practices.

8. A Willingness to go Off-Script. Being creative and being able to wield those surgical tools rather than only knowing automated suites. That’s the bulk of this point, but I dig that it hints at being able to employ some tradecraft, i.e. evasion and covert practices that change with every engagement.

9. Know that a Pentest is Only Part of the Picture. Pretty obvious!

10. Don’t be Afraid of Pentesters. I like this point, too, and it’s not as obvious or one that I likely would have thought about. Don’t be afraid of the testers; include them in your operations. Don’t be afraid to direct their work/output. A really good point and a great way to close out the article.