detecting malicious actors on windows systems through logs

I think I saw this passed around on Twitter first: Detecting Lateral Movement through Tracking Event Logs [PDF] from the Japan CERT. The blog link actually goes into more detail about the purpose, which is to assist incident responders. But this can be equally useful to incident detection to highlight some log entries to look for that may indicate potential malicious actors. This is also useful for pen testers who are tasked (directly or indirectly) with testing or evading blue teams. Even in a lab, a pen tester can initiate some of these attacks or actions and validate what they see or what artifacts they leave behind on systems. Near the end, there are even supporting steps to make sure proper logging settings are in place to see these events. (Gee, tracking Executing Processes pretty much covers most of it, eh?)

And like many settings in security, the paper at least makes mention that there are considerations to make before making audit log changes. For instance, tracking executing processes (or written files) will generate a large number of entries in the logs, causing them to fill up and roll over or flood your log collectors or SIEMs and maybe challenge your backup capacity. As always, keep in mind the big picture when making settings/architecture decisions.

Very cool list. It’s things like this that I have a hard time figuring out how to save and consume. Do I add a menu link in “resources” to the paper, keep my own list of this somewhere, or just hope to remember I have it here?

keeping up with infosec

How does one keep up with the Infosec world? It’s easy to get comfortable and keep doing what you’re doing as change swirls around outside the window. Technology and security have common themes over the decades, but many of the knobs, dials, and talking points change and we need to keep up with all the new ideas and products coming along every few years. It’s a simple fact that security experts are often used as sounding boards for new technologies and projects, which means keeping up and learning are key habits.

As a corollary to this topic, answering this question also means asking how you want to present yourself to the greater community of infosec online and in person. Do we stick to fully anonymous screennames, switch completely over to real names, or some sort of hybrid in between? This is a personal decision for everyone, but something to keep in mind when putting yourself out there virtually or really. This can be screennames, usernames, email addresses, domain names, and profile details and pictures and avatars. It may even steer you towards or away from certain forums and medium. It may also be dictated by your role, for instance malware researchers may stick a bit more towards the anonymous realms.

So, how do we keep up?

Old School collab: IRC, web forums, mailing lists, blog comments, ‘zines, and even books. These are still used, but they’re a little less prevalent these days. Mailing lists are nice to lurk on when they aren’t broken by spam filters. Mailing lists feel like they’re on the dying end of the spectrum, but does still remain as one of the better “push” methods.

New school social media: Slack, Reddit, Discord, LinkedIn, StackExchanges etc. These are still growing and are often only as useful as what you put into it. Reddit and LinkedIn are a bit more lurker friendly, but LinkedIn’s activity feeds are very noisy with only a few ways to manage it. I actually prefer Twitter as a news feed over LinkedIn, but mileage will vary.

Twitter deserves it’s own mention, as it really has become important for briefly meeting new people, feeding links to other information elsewhere (sort of filling the void from Google Reader), and getting quick notification of important events. If it feels like something major is happening like DNS is down or a major provider out, I often turn to Twitter to get a confirmation. Twitter becomes invaluable when at a con.

Infosec news feeds. It’s important to make some effort to keep up with incoming news and learning opportunities from blogs, infosec news sites, dashboards, exploit/vuln trackers and more. A huge bulk of this is still personal blogs to read, and I suggest Feedly to take care of a huge chunk of this segment.

Traditional news sources. It’s still important to keep up with some of the major events in the country and world, not just for impact on business and infosec, but to keep up with social talking points. It’s also important to know when something in infosec hits the mainstream news waves to prepare for incoming questions.

Podcasts and video. Both of these mediums kinda straddle the new and old school social media, but are more about delivering content to your eye and ear holes rather than more interactive formats. Audio definitely allows for a wide range of opportunities to consume (feet- and hands- and eyes-free). Video is still great for conveying highly technical topics.

In-person networking, cons, meet-ups both formal and more informal, local or more remote. These are great opportunities to learn from others and grow one’s own analog network.

Vendor demos, webinars, and events are great places to meet others, meet vendors, and see new products and features which are likely responses to direction in the overall industry.

Self-study, learning, and playing for fun. In order to continue to learn and grow, you need to enjoy the industry and process and work. And this means being a geek during down times and learning some new things, often on your own with self-paced study and tinkering with new things. These new things are often found as follow-up tasks to many of the above learning and exposure opportunities.

More formally, training and courses are available to do more structured and tracked learning of new things.

Lastly, getting back to how one presents oneself to the great digital and analog worlds is the tenet of giving back to the great community. This could be just participating with the mediums up above, but also by keeping one’s own blog, github, wiki, checklists, tools, scripts, how-to’s, or other content. It’s about giving back and being visible.

PS: Be cognizant of two more thoughts. First, think hard about mixing your infosec activities with your personal ones, and that includes the way you present yourself online. Again, this is highly personal and there’s no right answer, but sometimes you want to make sure your personal hobbies and activities are separated from your infosec world. This is probably most applicable to a Twitter presence. Second,  and conversely, don’t be afraid to plug some hobbies into these activities. A great example would be browsing Reddit or populating Feedly with blogs and news feeds for something you’re interested in or have a hobby around. Including sections and opportunity for these will make it more likely that you’ll check back in and consume these activities, and allow a little diversion from the same old intense firehose of security information.

building a malware detonation and analysis environment

Via Reddit, I saw and really like this blog post about how to “set up your own malware analysis lab with VirtualBox, INetSim and Burp.” Oh wow, INetSim fills a nice role in this, but the author also does go through almost every step you need to do to set up a couple victim boxes, an analysis box, and get visibility into the basics.

My lab is nearly equipped right now to do this, but it could with some adjustments based on these steps. I’ve never done full on malware detonation and analysis before. I have done malware analysis to a smaller degree many years ago on actively infected production systems. It’s definitely more sane to do this in a controlled, throwaway environment! Filing this one away to do on a rainy day where I’m inspired to do some malware analysis like this. I really dig the INetSim and Burp setup.

pushing sysmon monitoring for security ops

Saw this on Feedly as I futiley try to keep up with security feeds: How to track that annoying pop-up. Yeah, yeah, yeah, sysinternals, sysmon, tasks, blah blah, sort of junior sysadmin stuff. Wait, what is this at the end of the article? A throwaway mention of and link to SwiftOnSecurity’s sysmon-config custom config file for monitoring systems. Now we’re talking!

You can pay the bucks for a badass product to do your system monitoring for you. Or you can roll your own temporary solution for small troubleshooting tasks. And then there’s that huge grey area in the middle for small-medium environments where you might not have the budget but still want to do better logging. This looks like a nice way to hit the ground running with sysmon on the cheaper “roll your own” side of things.

I’ve, of course, used and considered SysInternals tools as toolkit staples since before I started professional work in IT. And yet, 15 years later, they still surprise me! I hadn’t seen that Sysmon could be used in such a way. Some tips are available here, and the official information found here.

I now need to remember to set this up on my lab boxes every time I refresh them…

training and learning plans for the rest of 2017

I made a post back in November about some future learning plans. Of that list, I’ve “finished” building my lab for the moment which allows me to put time into vulnhub boxes and other lab work. I successfully finished the PWK/OSCP course (whew!). I’ve started getting back to attending local meet-ups and events (SecDSM, BSidesIowa, ISSA). I also have a PluralSight subscription where I fill some free time with courses hosted there; they proved very helpful in preparing for the PWK/OSCP.

Moving forward over the next 6 months…

I’ve added and also started to pursue other online labs/CTF styled efforts such as I hope to make HTB my larger time spend for geek stuff over the summer months. Add this to Vulnhub lab efforts and I should have my puzzle-solving itch taken care of for at least the summer. Also, doing these hits some sub-goals of organization and learning a few new tools.

Work is footing access to the LinuxAcademy course site for 6 months with the goal that I will be completing one of a few 20-ish hour tracks in Linux. Obviously, I’ll take advantage of more courses than just that. My own goal is to shore up some of my Linux exposure. I’m comfortable in Linux day-to-day and command line operation, but I still have lots to learn and I do plenty of administration-by-Google. I’d love to eventually just add in a RedHat or LinuxFoundation or Linux+/LPIC certification under my belt. Probably one of the former two by end of 2017 or early 2018.

I am also impatiently waiting for the online release of the Offensive Security web application course, AWAE/OSWE. This isn’t live yet, but once it opens, I plan to get in on this to further my web application security assessment skills as a priority. I could also pursue self study on the syllabus or using books like the Web Application Hacker’s Handbook in the meantime. Failing that one coming out any time soon, I’m also open to looking at other web app security/assessment courses or certifications. Examples include eLearnSecurity’s eWAPT course, or maybe the CSSLP from ISC2.

For possible other directions later this year, the next Offensive Security offering CTP/OSCE is an experience I’d like to have finished by the end of 2018. But having done OSCP, I know this will be another time suck. I’d like to look into the SLAE from SecurityTube as a pre-cursor.

Also, the CompTia CASP has appeared on my radar of something to pursue, and seems to be getting good exposure and reviews. Other possibilities are the CCNA as a way to get into the deeper Cisco security stuff or doing some other vendor-specific stuff like Palo Alto, Fortinet, VMWare, AWS Cloud Security, and so on.

My lab does still need to have a plan implemented for standing up (and re-standing up efficiently) an AD environment that I can use for testing. I’d like to package some additional PowerShell and maybe even Ansible/DevOps concepts into this effort, but that might be too big of a scope.

And a bit further down the priority list would be something like the ISACA CISA/CISM or much deeper study into Python.

There’s an endless amount of learning to do!

local file inclusion testing from hakin9

Ever since Hakin9 stopped being carried at Barnes & Noble, it’s been pretty persona non grata to me (I would read it for free over lunches spent at B&N). But I see it’s still alive with an article titled, “Web Application Penetration Testing: Local File Inclusion (LFI) Testing.” Is this the definitive guide? No, but it’s surprisingly useful and covers plenty of bases. Also uses DVWA for examples, meaning you can do some follow-alongs.

I do want to point out the php://filter/convert.base64-encode/resource=/etc/passwd section. This is highly useful if output of files isn’t very pretty, usually meaning carriage returns are not displayed properly. Outputting into base64 and then decoding it means things like long config files aren’t hell to read.

cloud security case study from threatsim

Everyone is at least thinking about cloud computing and security to some degree. Few people get or know what to look for, and fewer yet on how to do it. A multi-part article has been posted by Stratum//Security about building and using ThreatSim in the AWS cloud for several years. Part 1 is largely marketing fluff and context (though the security controls bullet list is very good to steal!), but the latter two parts start going down a bullet point list of things to keep in mind for cloud security.

This is certainly not all-inclusive, but every little bit to add to the body of cloud security knowledge, the better. Cloud security includes pretty much everything for more traditional security, but also almost doubled in order to cover things abstracted out to a whole new layer in the cloud platform tooling.

pwk and oscp advice to my younger self

This is part 2 of a 2-part post. The previous post was more about me, while this post is more about advice for others.

Success in this course comes from two things: experience and knowledge brought to the course up front, and how much quality time is put into the course while taking it. This makes it extremely difficult to gauge what someone needs to do to prepare or how one should approach and study. Some students will fly through the labs due to their large amount of free time or pre-existing skillsets, while others will take a few months to get the ball rolling up their steep learning curve. Every step of the course and the lab discovery and pwnage is a separate journey; even researching things that turn out to be false leads takes time and energy. The goal is to get the most out of the course, and that is often about putting the time into it.

Some Basic Foundation

Try to become familiar with the Kali Linux and the tools it has and the layout. This will be your home base for the course, and has pretty much everything you’ll need.

For those newer to Linux, start using a distro on a day-to-day system and find some online courses on Linux security and administration and shell scripting/commands.

For those newer to Windows, find some courses on Windows security and OS administration.

Learn some Metasploit. It’s worth it and it’ll get used, whether in the course or beyond as a pen tester. Off Sec has a free Metasploit Unleashed course.

Learn some basic, staple tools and get comfortable with working various switches: nmap, unicornscan, curl. Google the top 100 security tools.

To get familiar with some of the big issues over the past 15 years, grab a copy of Hacking Exposed (McClure, Scambray, Kurtz).

For pen testing theory, check Penetration Testing: A Hands-On Introduction to Hacking (Weidman) or the slightly more up-to-date The Hacker’s Playbook 2 (Kim).

Have a decent enough grasp of networking to know how TCP/IP works in general, use and read some Wireshark/tcpdump output, and understand IP addressing, firewalls, and ports.

Have a decent grasp of our web technology works, from configuring web servers, looking at simple HTML/PHP/ASP code, and how browsers interact with the web server.

Install some security-related add-ons and poke around the Developer tools in place in every major browser these days (F12).

Dive into Python or Perl enough to get into Socket programming. Very useful to start swimming in the ocean of editing or making exploit code or enumeration scripts.

To Be a Successful Student…

For most students, this will be the very first taste of anything to do with pen testing beyond reading a pen testing report someone else produced. As such, think about what pen testers do with their jobs: scan and attack systems, keep and organize and protect notes, create client reports, research, and learn. Students should be going into this course looking to hone and taste and practice every piece of that job role.

This is an entry level course and certification for an IT discipline that is not itself entry level. Security combines everything and a little more from other IT disciplines. Pen testing touches them all, and is certainly not an entry level route into general IT. That said, the PWK/OSCP is, by necessity, still only a small taste. As such, students should have some exposure to Linux, Windows, networking, coding, web technologies, Metasploit, shell scripting, and Python, among other more specific experience. In general, the more enterprise level troubleshooting done in these topics, the better.

Find a support group somewhere to turn to, even if it’s the spoiler-free IRC channel. Be ready to put some time into this as well, from a social standpoint. Help others out and befriend a few peers. Don’t be that person who just wants to leech answers. Give something back and grow your network. Plan on this taking several hours out of each week to maintain relations. To be fair, this is the biggest difference in the course today from my previous experience; the social opportunities and other learning services are amazing today. Don’t ask for answers; don’t give answers away; help yourself and others learn by doing and figuring things out.

The course isn’t teaching anything brand new to the world. Be ready to consume resource material quickly, efficiently, and effectively. Sometimes there is the need to read manuals for tools or apps, or even find them first! Be good about using Google and analyzing search hits efficiently and effectively.

Rely on Metasploit exploits as little as possible. When source code is found, try to run the attacks manually. This is largely to help understanding, but also test prep since Metasploit use is explicitly limited. When time is available, put in some research and effort into manual attacks, even up to porting Metasploit ruby modules into standalone Python/Perl/Shell exploits.

It’s ok to find something obvious and focus on just that thing, but the better bang for the buck involves taking notes on ideas, but moving on and making sure to at least lightly touch everything available. There might be something even easier to exploit, especially since so many lab machines have multiple routes to root. This means going fast isn’t a great measure; it’s about being thorough and finding all the lessons offsec has prepared in the labs. When looking at the whole lab, it is known that every system has an issue. But it is not known if every system has more than 1 route to root. This adds realistic uncertainty to methods and time spend.

Figure out how to keep notes. Think about how to document vulnerabilities and exploits enough that allow a client or future pen tester to recreate the steps and validate the results or the fixes. Test the notes in a few weeks by re-rooting boxes from the notes.

Do the course exercises and lab report, and be aware these two items will eat up 2-3 weeks of time (that’s what it took for me with a full time job and other responsibilities).

Words to My Younger Self (of 3 months)
Clearly, what I brought to the labs and what I did in them helped me pass the exam, but I feel like I could have done even better had I changed some things. I had more than several takeaways from my lab and exam experience that I would pass on to my own self of 3 months ago:

Rely on the forums less. This is really a balance that is going to be very personal and difference for everyone. For me, I think I relied upon the forums too much for hints that lead to answers. I’m very good with puzzles like that, but I think I should have found more things on my own. It’s a balance between money spent for time on the course, against one’s own knowledge, against one’s own background and familiarity with the OS versions, against being able to troubleshoot the clear issues. I think I used the forums too much on my quest to get x roots in y days. The quality of the learning, methodology, and accuracy is more important than speeding through and tallying up pwned systems. I learned this way too late.

Just to reiterate: Do not put so much emphasis on the quest to get x roots in y days!

Even when rooting a box with hints, troubleshoot and fully understand the opening used. Do all payloads work? Do other characters work? What limitations are there or requirements? Can I leave off the null character or does it need it? Can I play around with various sqli bypasses or does only one work? This sort of curiosity helps go faster and more confidently on subsequent similar boxes. Don’t just get root, loot the box, and move on. Absorb and analyze the holes for full understanding.

Get better at knowing what is normal on a linux system for various distros. What are the default services and their runlevel? What are the default SGID and SUID files? What are the default cron jobs?

Once comfortable doing these manually, script out the very basics of the initial enumeration scanning. Unicornscan->nmap-> maybe a nikto or dirb or enum4linux scan immediately. Those are time consuming to wait through. I may as well throw in a few curl gets since I do those every time I see a web server/port. Taking this too far snowballs into huge scripts that steals away learning from doing things manually, though. The real goal: to be able to kick off a scan of x boxes while working on a different one without interruptions. This will help on the exam, but also in the field. But don’t take this so far that manual tests and results are missed.

The methodology is king, but the vulnerability trivia and experience in the labs is a close runner-up. But still, make the methodology the main key. I’m a big believer in checklists, and I have enumeration checklists that I continued to update and maintain from even my early lab wins. Learn from others and continue to build what works for me.

With every rooting look back at my process and ask: What can I do to find things like this quicker? Am I missing steps? What clues lead me to this answer and how do I make sure not to miss them? Always review your process after each box and update your process/checklist. I did this, but not enough for my taste.

Make a list of lessons learned from each box. Try to keep them in one location so you can review later and make sure you do know those things. incorporate every experience into your full body of knowledge and skill. I also did this, but again I should have slowed down and done it more.

Train a bit for the exam. 5 boxes, 24 hours. Sit down some day and tell yourself “I will spend 3-4 hours on this box and be done.” See how that goes. See how your work space and notes look when you hit your cutoff. Move to another box and spend 4-5 hours again. Any success? Weaknesses? Fatigue? Did the break from the first box spark some ideas? During my time in the labs, I sat down on a box and stuck with that one box until rooted (30 minutes to 16 hours) with only 2 exceptions where I had to walk away for a while. This didn’t prepare me for the exam.

Do not be afraid of the exam! For me, I learned almost as much about myself and my knowledge during 48 hours of exam time and cooldown as I did in about a month of lab time. Failure is not embarrassing on this exam! It’s a chance to figure out what needs to be done to succeed further. I should have been ready for the basics of it and taken a crack earlier. If I had failed my first attempt when I took it at 90+ days, I would have had to look elsewhere beyond the labs to improve myself for subsequent attempts.

Figure out a way to stay organized on the desktop. After the exam, I had about 30 terminal windows, 4 firefox windows (with several tabs each), and 10 unsaved text files hanging out. Doing 3-4 systems at one time means being organized, not just inside your mind, but also on the desktop. Get better at tmux or other terminal helpers like screen or get dual screens going. I did fine when doing one box at a time, which is how I tackled the labs, but this got out of hand during the exam with 5 boxes at once.

Figure out a way to automatically record commands issued and/or terminal output. It’s a waste of time to do this manually. asciicinema and screen.

Get better at DLL sideloading and windows executable payloads. I just didn’t find as many opportunities in the labs to do this as I thought I would, but that likely means I just missed them.

I still have lab time this month, and I plan to tackle a few of the last items on this list while I have that time available.



reflections on passing the pwk lab and oscp exam

This is part 1 of a 2-part post. This post is more about me, and the next post more for advice for others.

Passed the Exam
Over this past holiday weekend, I took and passed my OSCP exam. I started this course back in 2008 as detailed previously, but nothing I did back then really carried over to my knowledge base today other than knowing how the course works. I became interested in completing this unfinished task in November 2016 and I signed up for 90 days as March 2017 rolled in. My initial goal was to get about half the boxes over my 90 days of lab time, but I exceeded that pace and adjusted my goals as I went along. After 66 out of 90 days, I had rooted every target system in the labs at least one way (many systems have multiple avenues of success, and I by no means found close to all of them). I extended my lab time 30 days just before taking the exam (for further research regardless of pass/fail), and took the exam on day 90+3.

The point of this and the next post is to give my insight into the course and exam experience. There are dozens upon dozens of exam reviews and stories out there, so I’ll try to keep this somewhat different from the many others. There won’t be a litany of links to cover topics to study (which is a bit ironic considering my links menu on the side). To be honest, others have proctored far better lists than I would provide. Go search them up!

My Background
I have 17+ years casual own-time interest in security. 14 years of IT technical work, mostly systems and networking plus security defense management. I am comfortable with scripting and coding principles, comfortable in PowerShell, novice-to-intermediate in Linux administration and working inside it, good with general networking, and extremely knowledgeable about Windows and systems/servers.

This means I bring a pretty decent history of knowledge and exposure to security concepts, even if I’m not always actively utilizing those skills and putting off-sec-style boots on the ground. My professional IT jobs have included doing things with security in mind. I use Linux Ubuntu as a day-to-day desktop at home. I’ve used BackTrack and Kali, and I’ve rooted a handful of boxes in the past using Metasploit or very simple tricks. I’m pretty learned over the years and understand technical concepts, but would still consider myself a bit of a neophyte to the deeper workings of hands-on pen testing.

My Pre-Course Activities
I did a bunch of things to lead up to my PWK/OSCP sign up, but the most important was simply reading other OSCP reviews and feedback and study lists on blogs, reddit, forums, youtube, etc. In doing so, I made an absolutely unattainable list of things to reference and check out, and I sort of tried to prioritize and tackle that list.

I checked out vulnhub and built a better lab environment at home for further study.

I slowly found some of the new and old places that students hang out and socialize, notably a private Discord server off the forum, a Slack off the netsec sub-Reddit, and the #offsec IRC channel.

I signed up for Cybrary and Pluralsight to take some courses to shore up some of my weaknesses and areas I’ve not been heavily exposed to: shell scripting basics, python basics, linux administration, kali and enumeration basics. To be honest, those Pluralsight courses were overall very helpful!

Being a previous student, I was allowed to upgrade my course materials for a small upgrade fee and download them without having to purchase more lab time. This proved to be awesome, as it allowed me to start studying the material without having it happen while my lab clock counts down.

I installed and started getting used to Kali Linux again as both a VM and a dedicated laptop, plus incorporated KeepNote into those installations and my normal Desktops and synced using Dropbox. (Note: In the actual PWK labs I only used my Kali VM that was downloaded as part of the student lab signup and never did an update to it nor had to ever revert it. I also switched away from KeepNote to CherryTree about 2 weeks into my lab time due to issues.)

Importantly, I made sure that I could sign up for the labs during a time where me, my job, and my loved ones were ready to accommodate the time-suck that is required for this course.

labs halfway complete for the oscp

Just to keep myself accountable, I wanted to make mention that this last weekend I passed the 45-day mark of my 90-day lab access time. I’ve root 41 systems with maybe a dozen-ish more to go, and have gained access to all networks. My rate of success slowed down in the past week, but that’s partly a function of having less targets to choose from, but also taking some days off to reset myself. I’ve had a few boxes here recently that I felt pretty burnt out while doing, and my performance suffered for it. However, the lessons being learned, even when not successful, have been wonderful and help build out my knowledge and experience.

At this point, I need to start looking forward to scheduling an exam time, and efficiently mapping out the rest of my lab time and/or time leading up to the exam date. I’ve over-achieved what I had as a soft goal early on (getting 50% of the lab machines done 50% of the way through my lab time), which is a good thing. This means I can have a shot at actually clearing the labs and still have some time to prepare for the exam specifically. I may still not meet that goal, as I have some tough systems ahead yet, but should be a healthy goal to shoot for.

Other tasks I have to accomplish yet: Finish the exercises in the PDF for bonus points on the exam and CPE credits. Master the Buffer Overflow concepts. Run through the lab systems again while tightening up my processes, documentation, and reinforce exposure to the vulnerabilities and exploits I’ve leveraged. Tighten up my quick reference notes and checklists.

the pwk (oscp) course take two, or where my free time has gone

Back in 2008 I signed up for the Pentesting with BackTrack course and Offensive Security Certified Professional exam put on by the folks at Offensive Security. I even blogged about enrolling and getting started on it. Just to put this into perspective, this was back in 2008…when BackTrack 3 was still in beta! I also have a 4 digit OS-ID number…old school!

As alluded to in those old posts, I ended up getting immediately swamped with unexpected work at the exact same time I signed up for the course. And while I was able to slowly consume the videos and PDF materials over small moments, I was never able to really get much going in the labs. I was pretty mentally spent in those days after work. My lab time expired with no exam attempt made.

But I’ve never wavered in my interest in the certification itself and in finishing the cert out.

So last year I renewed my course materials for a small upgrade fee, and near the end of February renewed my lab time.

I’ve had 20+ days in the labs out of 90 so far and have rooted 28 out of the 50-ish systems that exist. I’m pretty happy and stoked with the experience and learning that is happening this time around. And while I do like my progress, I still have plenty of room to grow. I need to get faster and more practiced with my process if I want to feel good going into the exam. I also have avoided some of the known harder systems in favor of “easier” wins and gradual escalation in difficulty. At least as much as I can with otherwise blindly picking targets. I’m at least happy that I’ve been able to make progress and not have to walk away from any targets yet due to lack of success; if I’ve targeted a system to take down, it has always eventually gone down.

I do have other sub-goals as well to accomplish during my 90 days of access that go beyond just preparing for the exam. I want to get every box in the labs down, and then I want to do them again with only minimal assistance from my past notes; I want to make sure I know the clues to look for, why they’re clues, why certain things work, and maybe even find new avenues of attack as many boxes have additional issues. I want to also run OpenVAS against as many as I can get credentials to, to see if I can find things I missed. I also want to make sure that I can run through as much of the labs as I can with Metasploit and without the automated tools. The exam will limit usage of automated tools, but the real world of pen testing will not, and I’d like to take advantage of the excellent lab environment while I have access to it.

So far it’s been a blast, and while things might slow as I hit harder systems, I hope to continue my success over the next few months!

central iowa security geeking out rundown

You’re moving to Iowa and you’re a security geek. Or you’re new to the profession and looking to get on with your career. Where do you go to hob-knob with your people? Here’s a quick 2017 rundown of what I know about the central Iowa/Des Moines security scene.

SecDSM – Probably the most informal of the groups here and stays vendor-neutral. Has a Slack that I’ve not visited. No registration, so just show up! Meetings are after working hours
ISSA – 4th monday of every month, meetings should usually be open to the public.
ISACA – third Tuesday of every month, meetings do often have a door fee attached, with discount for ISACA members.
Infragard – most meetings require pre-vetted membership, so inquire before attending. Background check is part of the vetting process.
ISEAGE Red Team events – get yourself on the mailing list for invites to be part of the red or blue (green?) teams for regular events every year hosted in Ames (usually) for high school and college level competitions.

BSidesIowa conference – April 22, 2017 (Saturday)
SecureIowa conference – October 3, 2017 (Tuesday)
DataConnectors – traveling tour of security presentations and marketers, which just visited Des Moines earlier this month.

And here are some local-ish businesses and friends that make for great places to check into for upcoming events beyond things listed up above. I know I particularly love seeing a major geeky movie at Flix Brewhouse for free with my friends and co-workers!
Cisco West Des Moines Office (I don’t actually know how to track this one. I usually hear this through the grapevines…) If you’re a purchaser of Cisco products, check with your local rep/seller to get on this mailing list!

What else is sort of nearby? Typically, events in Cedar Rapids, Iowa City, Ames, Omaha (NE), and Kansas City (MO) are attendable if you don’t mind the various drive distances. Chicago (IL) and Minneapolis/St. Paul (MN) regions are also doable.

And, if nothing else, there are tons of places to hang out, have fun, or eat sushi (or anything else) and drink away some security frustrations with small groups and friends.

it is still not time for pci dss to die

Saw an article saying that Arby’s has reports of a mid-January data breach of more than 350,000 credit and debit cards. This echoes a breach from 2016 by Wendy’s. I would link to this article, but it’s not necessarily a source I usually look at. If I find this mentioned elsewhere, I’ll add the link. If true, I’m at least interested in the short gestation time for that malware being present and someone noticing it! (Just like every breach, I’d love the full, un-redacted story from infection to discovery so I can gauge how truly impressed I may or may not be.)

One comment I noticed was asking if it’s time to ditch the useless PCI framework and get back to real security?

That’s a good question, and an easy answer for any company that is already enlightened about digital security.

But many are not, and PCI has been the only driver for any type of interest in security. Granted, those companies may still just be filling the checkboxes of the PCI requirements and not really doing much of anything of real ongoing value, but it does do a few things.

First, it mandates pen tests and third party examinations of an environment. You’re still only getting what you pay for, but this could at least expose some low hanging fruit.

Second, it gets a few extra tools in place that a company may normally not even bother with, such as IDS/IPS and code reviews or a WAF or firewall rule reviews. How many SMB environments run any sort of vulnerability assessment internally if they’re not asked to by a regulation? Very few. And those reports expose many small and large issues that can be fixed for little effort and high value.

Third, some of these checkboxes are in part driving the UTM market and other conglomerated boxes that combine many tools into one pane of glass and management umbrella. This is (arguably) good for everyone, and especially so as prices go down (a little) and quality goes up (a little), especially in comparison to an environment that just has outdated Antivirus, an old firewall, and nothing else.

Security efforts (and even things like making sure backups are successfully created) are things that almost always fall into second place behind revenue-generating events or tasks that support revenue generation. They just get done “tomorrow.”

We also need to remember that PCI DSS was created more to cover the butts of the card processors than it was to protect merchants and end-users. It’s also not the ultimate answer to security; it’s a framework that needs to be implemented properly for an environment and continuously effective. So maybe crying about the state of PCI isn’t even the correct place to be looking.

And no discussion of this topic would be complete without diving into the world of cyber/data breach insurance. If we don’t want to abide by rules, maybe we’ll just start eating the costs and call it part of business lumped into the insurance payments.

And lastly, it’s our duty in security to accept that axiom that breaches are inevitable. Even if you have a great security team or follow PCI DSS to the letter, you still have to assume a breach will occur. Hopefully many are prevented and the successful ones are detected and mitigated quickly.

If someone wants to say PCI DSS is useless, I’d really want them to offer up alternative solutions that can be applied to enterprises in many industries and or many sizes. Don’t just say, “Do *real* security now.”

security warrior 2.0 by kim jones

Kim Jones recently had a wonderful article talking about Building Security Warrior 2.0. I really liked his points and bullet items. I don’t think this is the whole answer, but it’s a very good one.

1. Defense Alone Is Not Enough – I’m not sure this is a really new point, but he does tie this in later on with how we’re shifting from governance and programmatic defense over to being able to think like an attacker on a technical level. It’s one thing to just play defense, but another to start anticipating the moves and weaknesses. That said, he’s also correct to walk this back a bit; it’s not about a security team attacking attackers (or would-be attackers), but it’s about thinking like them. And maybe, if you have a large enough organization that is a big enough target, to actually keep a finger near the pulse of parts of the attacker industry.

2. Security Is An Interdisciplinary Problem. – This times ten, although I do think he left off a bullet item in the list: Systems administration fundamentals. He lists network and app disciplines, but leaves out the system level. Anyway, it’s true otherwise. Some roles in security really are high level communication and leadership positions, while others are in-the-trenches technical ones. But there is almost always some level of upwards tendencies for all security people these days. You may be helping on a project with other teams at or above your pay grade or assisting with an incident that involves people *way* above your pay grade, and the ability to communicate and understand a wide range of security topics is important. This is why I find it harder to coach brand new employees out of college looking to get into security; often (not always) people should get some other sort of IT experience under their belt before sliding over into security, in my opinion. I suppose there are entry level SOC/NOC types of positions, but for anything above that, having some other fundamental skill specialties is really awesome.

3. We Need To Bring Back Critical Thinking. – This sort of goes without saying. Security professionals are fighting a game of innovation and discovery, and doing so across all functions of IT and across other non-IT functions. This means you need critical thinking skills that put you in and out of the box at all times. Often, security can be brought into project planning or operations incidents largely due to their wide and deep expertise and critical thinking skills, even if the issue at hand is not strictly a security one.

4. You Do Not Have The Option Not To Communicate. – Pretty much echoes points made above, but it’s nice to separate this out. As a security person, you’ll *have* to communicate to some degree, since security is (almost) always about making things a little harder (but more secure) for users and data and customers internal or external. Now, this doesn’t mean everyone in security needs to be able to talk and play golf with the CEO or be buddy-buddy with executive leadership. You just need to be able to talk to your audience, technical and non-technical, to get things done and understood. (Honestly, this is a key point for any level of IT support these days. You get every level of employee or boss that may come to you on any given day…)

5. Reality Matters. – Definitely this. Theory and book smarts and unrealistic research only goes so far. I definitely encourage anyone new in security to get their hands dirty, whether it’s with security topics, network/systems/app work, or sitting along for capture the flag competitions or shadowing current professionals. Security is not just technical, but it’s also part creativity and part gut feeling.

6. Information Assurance (IA) and Cybersecurity are Neither Synonymous not Mutually Exclusive. – Jones starts to get into some terminology here and this is where we tie back into the very first bullet point about programmatic governance and technical aptitude for attacks. I really like this line, “Part of that [pendulum swing towards IA] result…has been the increased volume and severity of data exposures, combined with the erroneous labeling of suck attacks as ‘sophisticated.'” Too many of these attacks are not sophisticated. Now, that’s a huge topic in itself…

Jones finishes the article with a list of attributes for the Security Warrior 2.0, and they really read like any security job description should start out. I think this is a really good foundational goal for anyone coming into security or looking to square their shoulders up again to where we’re headed.