Usually when I study for a certification or course, or even for comprehension on a topic, I have steps written down to check off on my journey to that goal. I’ve probably always worked off checklists, but it feels like I rely on them more as I get older, as there’s really no excuse to not use them and forget things or lose ideas to the ether. My time really does have a personal value, and I’d like to make sure I spend it well and efficiently.

When I decided to tackle learning more about cloud security, I knew the topic involved reading and listening to materials on a topic that I’ve not been highly exposed to. And I wanted to make sure I planned out how to spend my time so that I could plan the rest of my year and have an idea when to schedule exams.

The above screenshot is a sheet I maintain on Google Sheets. In it, I basically use a Gantt chart style format to track my progression of tasks and how long they will take. I estimate the hours involved,  record the actual hours I spent, and then the remaining hours and % hours used adjust automatically. The % Complete column I update manually. For instance, I may estimate 10 hours for a task, but find it only takes me 4 hours. I can then record 4 hours and still set it to 100% complete.

Do I really care how many hours are left? Not really, but it’s a way for me to practice skills for Project Managers-Lite and be familiar with a sheet like this. Lots of things that PMs do to perform and track projects are intuitive, pragmatic things that I can use for other purposes, even if I don’t know all of the specific terms in some Body of Knowledge.

And since this is just for my own personal tracking, there’s really no grading or performance evaluation based on how accurate or well I track this; it’s really best effort and its accuracy isn’t crazy strict. It’s truly just about keeping myself on target. (And, I suppose, it reminds me what I did on my route to a certification so that I can post about it later without much recollection effort!)

I will also add that one of the more important steps in pretty much every major learning effort I tackle is researching what others have done before me. This was a huge effort in something like the OSCP where I would read reviews and thoughts and threads from others who had experienced and passed the course/exam and what they recommended for prerequisite knowledge and resources to understand prior and during the learning phases. I still do this as much as possible, and it leverages strengths I have in effectively and efficiently Googling and sifting through information and then organizing and prioritizing what I really need to do.

As a last act of 2019, I took and passed the AWS Solutions Architect Associate certification exam. The AWS SAA is the typical starting point for sysadmins and engineers looking to design, plan, and manage an organization’s presence in the AWS cloud environments. Other exams at this level are the Developer Associate for developers and SysOps Administrator Associate for a more focused dive into managing systems in AWS. (SysOp is such a great, cool term. I hope it makes a comeback over SysAdmin…) Each of those three feeds into more advanced Professional designations and also some advanced specialty designations like Security, Big Data, and Networking. None of these need to be taken in order, but they do build upon each other so it makes sense for students to progress up the chain in order.

In mid 2019 I decided to shore up a gap in my technology knowledge by diving harder into cloud concepts and security topics. I’ve spent about 17 years doing admin and security work, but I’ve not had a large chance to dabble in AWS until my current position. So, I’ve decided to upgrade myself a little bit in this regard. Since then, I’ve earned my AWS CCP and my CCSK designations. I decided to remain aggressive and hoped to get this AWS SAA before 2019 ended.

My goal with this track of study is really to study for and take the AWS Security Specialty certification exam, since…well…I’m a security geek! The CCSP is also on the roadmap, but mostly for its recognition and the fact it won’t really cost me anything additional to keep renewed along with my CISSP.

For study, I really kept to the same blueprint I use for most certifications. I start out by researching the exam, the exam topics, and what other successful students have reported and reviewed over the most recent years. Often, I do this by searching the TechExams forum, reddit, and then also Google. I write down various ideas and resources those students used, research those sources, and start to formulate a plan of attack. Sometimes, I’ll solicit some advice from some peers on Twitter, Reddit, or other media, but often I usually self-research.

I opened up with a 7-day free trial to A Cloud.Guru and blitzed through their AWS SAA 2019 offering as quickly as possible. At 12 hours, this wasn’t too bad. But, also at “only” 12 hours compared to the Linux Academy course at 54 hours(!), I assumed ACG’s offering wasn’t really going to get detailed enough to rely solely upon. Overall, this course at ACG makes a good intro, but the presentation quality and style definitely go up and down. Some sections of the course are recorded with lower quality equipment, which means section to section you can experience very different sound levels. This becomes pretty distracting, even annoying. Likewise, an editor must not have been hired, as there are pauses and even retakes within the audio that are still present. Overall, I felt I could trust the author, but I also somewhat felt like the author rushed to get this out and it’s just not that polished. The material, however, was solid. I did not do any labs on ACG. I did like the meaty quizzes at the end of each section, though the grammar on them is spotty and the reasons for the answers are at times woefully brief, sometimes just repeating the actual answer rather than a reasoning for it

Later on about a week before my exam, I would open another 7-day free trial at ACG just to consume their Exam Simulator, which is just a practice exam whose questions are pulled from some pool of questions. I ran through this twice, and only had maybe 1-3 repeat questions out of the 65 given. That said, the grammar on these questions was outright terrible, and I honestly felt dirty for going through the experience. Still, plenty of questions reflected the sorts of topics and questions I saw on the exam.

I then spent the bulk of my study time on the 54-hour beast of a course, the AWS Certified Solutions Architect – Associate Level (id=341) by Adrian Cantrill and hosted on Linux Academy. This course includes LA-hosted labs which performed very well for me and a supplement, The Orion Papers, hosted on LucidChart. I was initially very lukewarm on the LucidChart materials, but by the end of my study, I was actually referencing them regularly for refreshing and reviewing various topics. The course itself is excellent with a high quality of delivery throughout. I did not like the quizzes nearly as much, but they do reflect the material presented.

I took the practice exam at the end of this course, and also an older LA-based practice exam from the 2018 course. I didn’t like either of these practice exams as they seemed overly specific on various bits of knowledge that go beyond what you are expected to know for the Associate level, like calculating RCU/WCUs. I found both quizzes to be strangely pulling from the same pool of questions (or at least written by the same people and/or borrowing from each other), and overall found it frustrating.

About halfway through the Cantrill course, I signed up for a package of 6 practice exams hosted on Udemy by Jon Bonso (TutorialsDojo). I really liked this set of exams and found them to be challenging at just the right level, both while I was still completing my studying, but also in retrospect after passing my exam and thinking back to where overlaps occurred between the exam and these practice materials. I initially was scoring below 70%, but as I finished up the core of my studying, I was pretty consistently getting 75% on my first attempts on those exams, and 85% on subsequent tries. I reviewed all questions after each attempt, making mental note of reasons for questions I got right, and physically writing down notes on questions I got wrong (or just guessed on). I would then re-attempt one of the practice exams after a week or more. Even if you pay full price for those (which I think is $40), this set of practice exams is definitely worth it.

Despite plans to do so, I never really consulting the official AWS whitepapers, FAQs, or Best Practices for the various services. I would sometimes get into them very briefly when Googling answers/reasons for practice exam questions, but never sat down to comprehensively go over them. I also briefly looked at the TutorialsDojo cheatsheets, but I had expected really quick cheatsheets and charts and diagrams, but instead they were pretty lengthy, so I didn’t really consume them.

I also never really went into depth on my own AWS account or fired up any projects of any merit. I would still say 80% of my AWS hands-on experience before my exam was fueled by the Linux Academy labs. That said, my extensive general IT experience hosting critical web sites helped me with many troubleshooting questions and understanding some difficult concepts like using load balancers, traffic encryption, and network layouts. Someone with less IT experience should probably expect to do a little more hands-on work in AWS to prepare for the SAA exam.

Overall, I somewhat casually studied from mid-September until the end of December en route to my exam date. For other students, I’d highly recommend going through the route I did: ACG course, LA course (Cantrill), and then Udemy practice exams. I’d then suggest looking at the AWS Whitepapers, FAQs, and Best Practices to finish up. If you already know about how AWS works, concepts on why cloud makes sense, how AWS bills you, how AWS support plans are structured, and the general one-line definition of the most common AWS services, I think AWS SAA is the place to start. Lacking that knowledge, first taking the AWS Certified Cloud Practitioner is a great stepping stone into AWS knowledge.

The exam experience wasn’t really out of the ordinary. I scheduled my exam during winter break at the college I usually take exams at, so the whole atmosphere was casual, chill, and pretty dead overall. I spent a full hour on the exam, and that even includes flagging questions and reviewing the first 20 questions over again. I did not feel entirely confident in my attempt after the first 12 questions, but they seemed to ease up in the latter portions. I normally do not review or go back to previous questions in exams, but I did do so quite a bit in this one. Still, I don’t think I changed many answers at all. It is possible to go back and review every question whether you flagged it or not, which is nice. Passing means achieving a score of 720 (possible 100-1000), and I scored 836 for a comfortable pass.

Overall, I think the AWS SAA is a good certification to ensure that someone who does already or wants to start working within AWS to design solutions and troubleshoot issues is prepared for that task. That said, I have next to no practical experience in AWS (that’ll change!) and was able to pass, so I would say this exam is appropriate for people with 0-2 years of experience with AWS services. That also means possession of this cert may not attest to someone’s actual expertise in AWS, but definitely attests to having a grasp of the fundamentals enough to not be a clueless disaster. (And honestly, that can even be said about the CCNA or any other technical cert.) Despite that, I actually feel far more conversant and novice-level competent in understanding and doing things in AWS, especially in comparison to my pre-study state. I’m hoping future projects will fill in further gaps.

As intimated earlier, the AWS SAA is a stepping stone towards my real goal of achieving the AWS Security Specialty certification, so that will be my next step on this journey. I also have the ISC2 CCSP on my radar, but I think I’ll keep with the AWS focus for now, and plug in the CCSP later. Since the CCSP is more theoretical than hands-on technical, I am skeptical what I’ll actually learn from the CCSP, but I may end up surprised!

Years ago, I became aware of the book The Phoenix Project (Kim, Behr, Spafford) and added it to my wishlist, but never actually picked it up. I remedied that issue over the past couple weeks by picking it up on Kindle and going through it. Rather than post a reaction or my thoughts on the book (at least for now), I just wanted to tell a small personal story that this book made me think about again.

Back around 2007, I worked as a sysadmin, and one of my main duties was supporting the servers hosting our critical web sites that developers developed. Thankfully we were already well into the virtualization takeover, but we were still using Microsoft’s Network Load Balancer tool to spread load across about 7 Windows Server 2003/IIS 6 web servers in one data center (the outfitted closet behind my desk). These sites ran .NET code using all sorts of virtual directories and COM objects tucked into corners of the server. And other things which I’ve thankfully lost memory of!

We had dev, test, and production environments, if I recall correctly. Deployments to dev and test took place Tuesday and Thursday afternoons, and would take several hours of manual work and testing to perform, during which time that entire environment was inaccessible to anyone due to the things needed to be done to support installations and configurations of IIS and COM. Part of the COM install was done by a homegrown tool built by someone I didn’t know and no longer supportable, but the rest was manual labor. And if one team needed a deployment, every other team pretty much had to feel that outage with the shared resources.

When I took this over, I immediately started doing a few things that seemed natural to me. I first made a clear checklist to follow for each deployment (know your work!), thereby removing the need to remember each step. I then started automating the pieces I knew how to automate using batch scripts to move files around.

At this same time, my company was also performing the implementation stages of a company-wide DR/BCP project. We added a second data center and my server farm was about to grow from 7 production web servers and about 4 dev and test servers into about 50 and more. We were also plugging in dedicated hardware load balancers as a much needed upgrade to NLB. And we then needed to solve file replication challenges when supporting two data centers that needed to fail over each other. Exciting times!

But this expansion meant I needed a new solution for deployments. Devops was still not really a thing. PowerShell had just recently come out, and I decided to try learning it in support of this coming build-out. I mean, no one wants to work for hours and hours just doing tasks that a monkey could do on servers.

So I created a PowerShell script that would perform these deployments automatically. My script would run on every production web server perpetually. They would all “check in” to a common configuration file and would “elect” a master who would do the controlling of another installation configuration file. When I needed something configured, my script would orchestrate the installation kick-offs with each other server in a predefined sequence. When a server received a command to do an install, the script would delete everything in IIS and remove all the other things, and then build them all back in every time. I had around 100 sites on these servers, and it was pretty glorious to see them all run through these installs for a few hours. I minimized downtime when possible (you know, database changes making this not possible) by utilizing the load balancer to know when a server shouldn’t have traffic, and when it was good to have traffic again. This was all replicated to separated (and expanded) dev and test environments as well as the servers on the DR site. Flipping over to a DR test was really just a matter of changing DNS and waiting a bit while the database then also failed over (pre-Availability Group days).

I solved quite a few problems with this setup. I lowered the amount of time an admin needed to spend doing deployments. I also lowered the amount of time overall for deployments. Deployments could be scheduled and run unattended at any time (weekends, nights). Outage windows were greatly reduced when they were even necessary. Most of the time, by orchestrating traffic direction by the load balancer, I could allow devs to do seamless deployments any time they wanted. I could scale this up (to an extent) to accommodate our expanded environments. I was able to achieve server consistency by not only removing human hands from the deployments, but because I rebuilt every IIS server, I eliminated those inconsistencies admins introduce when troubleshooting something, getting interrupted, and never getting back to set things back to how they should be. With a few networking exceptions, my dev environment was also comparable to the production environment, so if a developer could get their code to run in dev early in the dev cycle, it would also run in prod (none of this, “it works on my laptop!” crap). As a side benefit, no one could add something to the server that wasn’t part of the known build procedure, as the script would wipe it out or just not know to include it. And the script and its configuration file were self-documenting for what was needed.

Things were good, but they got better as time went on. When we migrated to Windows Server 2008 and IIS 7, I completely rewrote the script. I removed the need to pass a “master” token around and decoupled the script from the servers. I ran it on a dedicated system and utilized remote sessions to make changes on the servers. I also decoupled the actual copying of web code from my scripts and better utilized DFSR. This allowed developers to make simpler file changes within seconds if they wanted to. This also pushed management of “dev first, then test, then prod” pipelines to development hands, taking me out of that decision structure. I also made sure my script could install pieces and parts of sites rather than the whole server, if desired (will still keeping the ability to do a full clean and install). When moving to Windows Server 2012 and IIS 8, I again made smaller changes to improve support.

By the time I was done with the last iteration of my scripts, it was about 2013 and we ran that infrastructure until I left in 2016. We didn’t really dive too hard into devops, since we didn’t really have to. I had somewhat naturally found those concepts by improving delivery, improving consistency, reducing risk, and reducing my pain felt during deployments and in support of mistakes. No one should like to be forced into constant heroic efforts to keep the lights on.

Many of those lessons are buried in The Phoenix Project, which is really the same story of an IT shop in a (rather busy) company also discovering how devops improves IT operations. It doesn’t take an Erik oracle or threats of a business falling over to figure out how to improve operations or fancy production floor studies and terms to understand how to ease your pain and make things better. If you allow it, it should happen (to a degree) on its own as people manage their little fiefdoms more efficiently and reduce their own personal pain.

Had I remained with that company, I’m pretty sure I’d have next dumped my homegrown PowerShell scripts and done one of two things: Either continue with my fiefdom and implement more situated devops tooling like Ansible to manage the environment, or marry up to developers and their chosen packaging and deployment pipeline (their issue being they couldn’t get every team to decide upon just one).

The Phoenix Project has many more nuances; it’s like taking the IT issues of 50 companies over 5 years each and compacting them all down into one year of just one company. It’s a little silly, but it illustrates all the pain that eventually led many teams and engineers down the general path of devops. Which is still really just about keeping things in line with the whole utter point of IT: automation.

(This is an incomplete draft I’ve had for a while now. I don’t think I’ll ever complete it, but I didn’t want to lose it or keep it as a draft, so here it is.)

Daniel Miessler has a great article up: “If You’re Not Doing Continuous Asset Management You’re Not Doing Security.” You honestly cannot dislike that title, and the article itself is full of the points enlightened security folk should already have in their heads.

There’s a reason the top 2 controls in the CIS Top 20 Critical Security Controls are all about inventory. It drives every other thing you do in security, and without it, you’re managing by belief and never really sure if you’re being effective or not.

There are many different ways to tackle inventory, but here are some of the common ones:

• workstation-class devices – This is usually one of the easiest to handle, since the team responsible for workstation procurement likely has an inventory of what they have in order to please customers. Being able to tap into this inventory list, or at the very least view it, is essential. For instance, how do you know you have Antivirus or endpoint protection on every workstation? You have to true that up with the inventory list. Think about the question, “How would I know something is missing security control XYZ?”
• mobile devices (on your network and/or company-owned) –
• servers – Typically, one team manages workstations and another team manages the servers. This team should have a handle on some beginnings of an inventory system due to licensing needs, storage/compute resource needs, and other OS-specific collections such as Active Directory or patching coverage. But the same question applies herre, “How would I know something got missed in inventory?” Or in the case of a largely Windows environment, “How do I find a new non-Windows assets that is stood up without notice?”
• networking assets – This could include diagrams of the networks, both logical and physical when needed, for both wireless and wired networks. If the networking team manages it, it should be in this group.
• all other network devices – This covers all the other things not nicely slotted into the above categories, like appliances or IOT. This also covers unauthorized device discovery. Essentially, if something is on the network, it needs to be found and known.
• the cloud – The cloud is often a different beast, especially when consumed dynamically with assets coming on and off as demand moves. Worst case, you go through all other steps above over again with “cloud” in the front of it.
• internal information systems/sites – This is about knowing the information systems that your business and users consume, which often comes in the form of internal websites, but could be other tools and systems. Largely this is defined by things that store/handle data.
• software and applications – A huge endeavor on its own, but nonetheless important to know the software and applications in use and needed (and hopefully approved and tracked).
• external attack surface/footprint – This is what attacks can see and will target; high risk and high priority assets and paths into the organization. This isn’t just Internet-borne, either, but could come in through other weak links such as wireless networks or VPN tunnels.
• vendors – A good risk management program will have an inventory of all official vendors, which will fuel risk reviews and inform security of what is normal.
• third-party services hosted elsewhere – What services does the business and its users consume that you don’t strongly control? This likely will still impact account management and permissions, data tracking, and evaluation of those services since you have some measure of intrinsic trust in them which is a potential risk for you.
• critical business systems – This could be considered a little advanced, but it’s about knowing what’s really important to the business, which informs risk priorities, spending, and other activities like BCP/DR.
• data/critical data – You can’t secure data if you don’t know where it is, and have some idea on what data is more important than others. Yes, this one is difficult outside of narrow compliance definitions (aka all data vs just credit card data). Honestly, this bullet item should be a top level category in itself.
• authentication stores – This is about knowing what accounts you have, where they authenticate against (are stored), and what your users and systems actually use to do things.

There are different methods to find this out:

• process/documenting – This is the default method shops will use to track inventory. If someone stands up a new box on the network, they update some inventory sheet or make sure they follow some checklist to include the new asset in something else (adding it to monitoring, patching, or joining a domain). This is a trust exercise, as you need to trust that every team member follows the process and every process is all-encompassing. This includes decommissioning assets as well. This should also include the assignment of ownership: who in the company is ultimately responsible for this asset?.
• active/finding – Most of the time, security should assume the worst (trust, but verify), which would be finding assets that are weird exceptions or just get missed in the normal process. Active inventorying means looking out onto the network and scanning it, finding assets, identifying them, and pulling them back into visibility/compliance. The opposite is true as well, you want to find assets that aren’t meant to be there!
• passive/watching – There are also passive techniques to find devices, such as watching all network traffic or alerting (and even blocking) unauthorized assets from accessing the network. This is still a fallible control, but it is part of the puzzle of knowing what is on a network.

There are a few caveats to the above. First, it’s not 100%; there may be a “bump-in-the-wire” or other passive device on the network (think a network tap just collecting data). There are also device peripherals (mice, keyboards, headsets, readers of various types…) Tackling this is a bit advanced. Second, especially with the active methods, this needs to be done continuously, or the controls need to be continuously active. If you do active scans once a day, an attacker or insider could still turn on a device, do whatever, and turn it off in time for the next scan. Handling these windows is why we practice continuous improvement and defense in depth and why we map out maturity plans.

And Miessler includes 5 questions that drive the measurement of a security teams based on how they answer them:

1. What’s currently facing the Internet?
2. How many total systems do you have?
3. Where is your data?
4. How many vendors do you have?
5. Which vendors have what kind of your data?

(publishing an old “incomplete thoughts” draft) We all have a preferred environment and/or music we prefer to hack and learn and work in. Most recently, I spent much time at home practicing and learning in the PWK/OSCP labs and exam, and often to a background of music. I thought I would share some of my interests in this regard. If you read nothing else here, at least go give SomaFM a listen, particularly their DefCon Hacker Radio and Groove Salad stations. I’ve been a regular listener of Groove Salad since around 2003, and it’s absolutely excellent.

When I’m heads-down doing something, most of the time I’m probably listening to one of four types of music.

The most common for me is “chill out” music, largely electronic, but could also be acoustic or traditional. This largely stems from enjoying new age music from the 80s/90s, which then expended into electronic music through the late 90s and on (think Enigma and Kitaro transitioning into Underworld and Sasha). Unless I’m listening to my own stuff, this is where I’ll tune into Groove Salad on SomaFM. I don’t remember how I found the station or why or what led me there, but it definitely solidified “chill out” as a thing that I totally dig. (And I totally geeked out when BackTrack used to include a SomaFM bookmark in their default browser!)

I’ll also enjoy other electronic music, but if it has more intensity or a beat to it, I don’t include it into the chill category, and instead gets lumped all together into my general electronic folder. This encompasses anything from classic trance, goa/psytrance, dubstep, edm, and so on. I tend to stick to my own collection when listening to this, but might queue up a large set of stuff on YouTube, or use SoundCloud to listen to some sets or DJs, or maybe Pandora, or Digitally Imported feeds on TuneIn Radio.

Sometimes, I’m in a really heads-down mood or just want something less electronic, and I’ll turn to either normal classical music, or something less orchestral like cello, guitar, or piano artists doing their own thing. Most of the time when I listen to this, I’m firing up TuneIn Radio and just listening to the Iowa Public Radio Classical station. No ads, decent quality, good variety. Failing that, there’s tons of long collections on YouTube to listen to.

Lastly, I’ve also always enjoyed hard rock which borders into metal, but never really metal. I tend to be pretty picky when it comes to this (Metallica, Tool, White Zombie which betrays my age…), but more lately I’ve gotten into symphonic metal bands. I still have plenty of things I consider to be “harder” rock music (basically anything more intense than “pop” music), and sometimes that’s my mood.

A while back I earned my OSCP. I have written my reviews of it in two parts, once just on the logistics of my course experience, and another with advice to others. I often see requests on what to do to prepare for the OSCP or what it takes to earn it, and I have a saved response that I often give out to those learners. And I realized I’ve never really put it down here on my blog in complete format (a large chunk of it comes from the aforementioned advice post). So, here it is in entirety: my advice to people with the question, “Am I ready for the OSCP?” (A.K.A., part 3 of my OSCP series…)

---

Let’s first take a step back and ask this question: “What do you hope to get out of the OSCP experience?” In other words, “What is your purpose?”   

There are two main goals for the OSCP, though one really overshadows the other. First, the OSCP cert will open doors to pen testing and other security jobs; it’s a way to confer some immediate credibility amongst those who know what the cert is about. Secondly, and most importantly, the cert and lab are ways to teach pen testing methodology and frame of mind; how attackers work. It’s not about pwning more systems, or getting another add on the resume/CV; it’s about learning how to think like an attacker and efficiently evaluate systems and provide value for customers and admins.  

---

My OSCP prep advice is pretty much always the same, and yet it depends on what every student brings to the table. For me, if I were making an OSCP cocktail: 

• 1 part Windows admin – know how to turn services on and off, add users, change passwords, browse through cmd and windows explorer, RDP, etc.
• 1 part Linux experience – Know how to move around directories, read files, create files, use a text editor, create users, change passwords (linux essentials or linux+ prep courses will help)
• 1 part LAN networking – TCP/IP knowledge, ports, arp, wireshark/tcpdump familiarity, firewalls (host and network), dns
• 1 part security knowledge – general attack classes, goals, major OS vulns over the past 20 years; a pen test course or book works
• 1/2 part Kali experience – poke around it a bit, experience installing it, logging in, location of some tools and the interface
• 1/2 part Metasploit knowledge – have used it a bit, run through the free Metasploit Unleashed course
• 1/2 part web server/client knowledge – nice to have hosted anything with apache/iis in the past and understand config files, ports, php/javascript a little, client vs server-side processing, dash of SQL syntax
• 1 part coding/scripting logic/basics – if you can make a bash/perl/powershell/c/python script or have coded in the past enough to read and minorly edit script/code chunks, you should be good to start; nothing amazing
• Sprinkle of efficient Google searching ability 

Bring all of that or more to the table, and you’re set to be slammed in the face with the course material and then hit the ground running in the labs.  

Keep in mind, the course is an entry into pen testing; it’s not a requirement to have popped root shells in the past. The course will grab your hand and start you off the on the path. 

If you want the best example of what you’re in for, go to cybrary and have a perusal at Georgia Weidman’s Advanced Penetration Testing course. It’s free, and will be the closest and quickest way to see what you’re in for. Vulnhubs and hackthebox are fine for practice and to understand the process of enumeration, but they’re not necessary at all. 

Google for OSCP reviews. They are full of suggestions and resources, and usually give a great idea of what the course and exam experiences will be. Don’t over-mystify the course or exam, and thus, don’t over-prepare! Dive in and get on it. 

---

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. Linux+/LPIC-1 level skills are good, anything beyond is great. Also suggest a Bash Shell/Scripting primer.

For those newer to Windows, find some courses on Windows security and OS administration. This includes hosting server-type applications (e.g. web platforms).

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, free, staple tools and get comfortable with working various switches: nmap, unicornscan, curl. Google the top 100 security tools and at least know what you could use each one for. You don’t need to wield/install each one, but feel free to try any out.

To get familiar with some of the big security 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). The Hacker’s Playbook 3 is even more updated!

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 how web technology works, from configuring web servers, looking at simple HTML/PHP/ASP code, simple SQL queries, and how browsers interact with the web server.

Install some security-related browser 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 or web request programming. Very useful to start swimming in the ocean of editing or making exploit code or enumeration scripts. Having had a course or class in basic programming is great, as you can start to consume any language if you know the logic. (This is not necessary, but very nice!)

Start thinking like an attacker. This often comes with experience, but start thinking of ways you can get to Goal X or Access Y. What mistakes do you look for? What isn’t default?

Lastly, know that OSCP/PWK comes with course materials and videos that teach you everything you need. So don’t think you are going into this being tested from day 1 and spend 2 years trying to prepare for something that is meant to teach you new skills in the first place. You’re going to be learning from day 1 until day X.

---

So, what can you do to practice, if that’s what you feel you need to do? Download and install a Kali VM. Join Hackthebox (HTB). Watch Ippsec YouTube videos on retired HTB boxes and follow along. Download VMs from vulnhub and follow walkthrus on those boxes. Read OSCP reviews for more viewpoints. Pwn and have fun!

A few weeks ago I took a couple exams and passed them both. One was the AWS Cloud Practitioner exam. This is the entry level AWS certification that teaches students how Amazon Web Services works, the services offered, and the pricing and billing concepts. AWS suggests people with 6 months of experience with AWS should attempt this course, but honestly that could probably be less.

I have been working in IT since 2002 and as a systems administrator since 2004 with heavy emphasis on web support and infrastructure. I have a deep level of knowledge on all sorts of concepts that helped digest and understand AWS offerings pretty quickly. But, other than maybe a singular hands-on workshop a few years ago, I’ve really not been hands-on or actively knowledgeable about AWS at all beyond hearing about insecure S3 buckets and this Lambda serverless craze. And really, my lack of knowledge has probably been around not having personal time to dive hard into it, and also until recently not having worked for a company that adopted anything cloud-based.

And that brings me to my motivations, which foremost includes the business I work for going hard into cloud adoption in the next couple years. Also, as I get older and technologies come and go, I do feel the need to remain current, or at least conversant with current stuff. And I really felt like there were two places I could improve and grow a lot: application security and cloud (AWS) security. So, to tackle the latter topic, I’d decided to soft-scope some AWS studying into the second half of 2019.

I opted to start with AWS Cloud Practitioner mainly due to the fact that I really didn’t think I knew AWS enough to pass that exam if I had taken it 6 months ago. And that would have been true! There’s zero chance I would have passed, and likely not even gotten anything but the concepts/benefits of cloud-computing correct. The goal is to go further, so this cert is just a stepping stone into AWS.

For study, I followed a pretty quick timeline lasting only about a month. I had planned to take a little bit longer when I was less sure about the scope of the material, but in my timeline I built in a review period where I would drop other ideas and tasks if I felt like things were progressing well and I had overestimated the exam depth. That was a good idea, as I ended up finishing the exam in something like 20 minutes with a 957/1000 score, and saved several additional weeks of work and study.

I first signed up for a 7-day trial at ACloud.Guru. I had read that they’re a great training resource, but maybe could go deeper into some topics and best consumed alongside a second resource. So I started there. I then cancelled my account on day 6, so I really spent no money on this step.

I took Introduction to AWS (1 hour), AWS Certified Cloud Practitioner 2019 (5 hours), AWS Certification Prep Guide (2.5 hours), and as a bonus to myself, the Mastering the AWS Well-Architected Framework course (4.5 hours). Most of this was pretty good, with the clear standout of the Well-Architected Framework course which was excellent, and easily digested due to my background. Still, I didn’t feel completely prepared for the exam. It’s hard to tell for sure, but I suspect I may have been a lot closer to the passing cut off if I had just done these courses.

I also started working through the Udemy “course” AWS Certified Cloud Practitioner Practice Exams 2019 by Neal Davis which I purchased when it was on sale for $20. These are 6 practice exams and probably ate up about 10-12 hours of effort to take and review them. I highly recommend going through these practice exams. The only caveat is that these exams are decently harder than the real exam I took. But, that’s a good thing! I scored around 76-86% on these.

I also have a Linux Academy subscription already, so I augmented my studies with a newer course AWS Cloud Practitioner (CLF-C01) by Tia Williams (11 hours) . There are also some labs scattered in here, which, while very much just follow the instructions and click things, was nice to get some hands-on time for me, since I really haven’t had any. Also, note how this course is much longer than the one from ACloud.Guru. In my estimation, had I stopped and not done this Linux Academy course, I’m not sure I would have passed the exam; it would have been close!

I also made a couple Coggle mindmaps during my studies to keep track of the groups of concepts and services. This was a wonderful idea I found mentioned on another blog review of the course. ( https://www.shanebart.com/aws-cloud-practitioner/ )

As a last step, I took a few hours to breeze through actual material from AWS, namely the Overview of Amazon Web Services, Architecting for the Cloud: AWS Best Practices, and How AWS Pricing Works whitepapers.

As I said, I had more things planned, but I suspected this is more than enough to pass the exam, and apparently I was correct!

Moving forward, I plan to do more cloud studying before the end of the year. Next, I’d like to read the materials for and pass the CCSK certification. I will then start preparing for the AWS Solutions Architect – Associate exam and start doing some AWS projects. My ultimate goal is to earn the Security Specialty in early 2020 and maybe the CCSP later in 2020 as well. I’m still being a little aggressive here, but I think this is doable and a little less pressuring like lots of my other heavy technical studies in the past few years.

I would also say that unless someone is comfortable discussing the various services in AWS, the benefits of the cloud, the pricing structure of AWS, and the support offerings, this cert is a good and pretty inexpensive (in time and money) option to get started. Otherwise, for others with comfort in the above topics, it may be worthwhile to just dive into one of the Associate level tracks.

Less than 2 months ago I sat for SEC542 at SANS East in New Orleans, and this past Friday I sat for the GIAC Web App Penetration Tester exam and passed with a 97%.

My goals and background. My purpose for taking this course and exam was to gain more experience and comfort with web app pen testing methods. I’ve worked in web server/client environments as a sysadmin and security admin for many years, and I’ve had some exposure to web offense tactics and tools from the PWK/OSCP days and from various HTB boxes as well. I’ve not made or maintained any “modern” web sites, but I have some web coding experience back in the painfully early years of the web and feel comfortable reading or tinkering with most preexisting code. Going into this course, I already knew some of my weaker points: I am not entirely confident with SQL and sqlmap; my exposure to Burp Suite seemed limited (and exposure to ZAP being nil); and I also had not done much with Python in regards to requests and web work.

It speaks more to myself than to the course that I probably overestimated the material a bit (or underestimated what I already know). Pretty much across the board, with my offensive experience above I had probably seen and performed most of the attacks that we went over. That said, my weaknesses listed above were largely addressed. But, beyond working more with Burp, ZAP, sqlmap, and python, I really ended up being somewhat ready to move past this material. Now, that’s not to say I’m ready for advanced stuff, but I think it might be more accurate to say I’m ready to gain more progressive hands-on experience with testing web apps, either live or vulnerable testing apps.

My study process. After taking my first SANS/GIAC exam last year, I formulated what I would expect to be my repeatable process for studying for future exams. But, for SEC542, I definitely deviated from that process and skipped quite a few things. Once getting back from class, I started skimming through the material, doing a first pass on highlighting key terms and concepts. I have a process of highlighting tools and external resources that are tool-like, like cheatsheets, with an orange highlighter, terms and definitions and concepts with a green highlighter, and I underline in pen anything else useful so that they catch my eyes when I’m looking for answers later. If a topic continues on the next page, I put a highlighter arrow to the next page.

After that, I worked through all of the labs again, which I admit, was a very quick breeze as none of the labs are really that complicated or long. In doing so, I also highlighted information in the Workbook just like I did the other books.

The index process. Next, I started work on the index. Now, this course has a Day 6 CTF book, and in the back of this book is a very rough index. Sadly, I didn’t really like the index, but I also didn’t want to leave a trove of information on the table, so to speak, so I spent a few days transposing that index into my own index spreadsheet. Once done, I then started with Book 1 and began augmenting that given index with my own index items, as well as the definitions and concepts I wanted for each term. I did this for all of the daily books (except the CTF one) and the Workbook.

The way I make my index is to just have three columns: term, notes, page (1-101 format). I don’t shy away from expanding the size of a row if I need lots of text (word wrap). I separate each book into its own sheet, and I copy/paste those sheets into a master sheet which I then order alphabetically. The workbook is referenced as w-101. If I add something from another source, like a practice exam answer explanation, I’ll just mark it as x. I’ll then later get it printed and bound at Kinkos. This time around, it took $19 to print and was pretty thick…

I took particular time this go around to make note of any commands and screenshots of tools. This way, if on the exam I am looking at a tool output or some command, I have a shot at finding a comparable bit of output in the materials for comparison. Often, I would put the command verbatim into my description for that line, as nothing but sqlmap were really long.

The goal of an open book exam is to be able to efficiently and correctly answer questions by using those materials, and to do that, you have to manage your seek time. And that seek time plus tolerance for recollection or finding exact answers is going to differ from person to person. For me, I like enough context on each line of my index that I can tell where I should look for something about XSS types when I have 15 individual references to “XSS.” I don’t expect to always find answers just in my index, but I do give myself a shot at doing so. Ultimately, however, I expect to get into the books and find the “for sure” answer quickly. I do this with my index, but also sometimes with tabs along the tops of the books for key pages, tools, and topics.

In retrospect, I’m not really sure how useful the provided index ended up being, as I trust my own index was probably going to cover the bases. Honestly, the given index had some mistakes and included some weird terms from some weird places that added nothing. In the end, it maybe just resulted in a larger index than the FOR508 index I mast last year (and I think that material more warranted a larger index).

One note about the SEC542 material that I noticed. Way too often for my tastes, the authors didn’t actually define terms. Instead, they would describe them anecdotally, and maybe list some uses for that term to be gone over in more depth in later pages. This made defining terms very strange, and it added extra references for terms. For instance, Stored XSS is mentioned well before it is actually dealt with, but I had to keep both references. (I suppose you don’t have to, but *I* had to, if you know what I mean.) I also challenge you to find a succinct definition of XSS somewhere. I think I would have appreciated a bit more structure in that regard, but the material is effective either way. On the flip side, I like the “attacker perspective” that closed out various attack topics.

The rest of the preparation. Once I had my index finished, I tabbed the tops of the book pages. This makes for easy flipping to sections when I know generally or exactly where a topic is in the materials, letting me skip the index completely sometimes. This was more useful in the FOR508 exam which has more repeated reliance on tables and charts, but I did find myself using these on the exam as well. For example, a digest authentication question is going to be in the….drum roll….digest authentication section! There’s really no hunting around needed in that case.

Before sending off my index to be printed, I first took my first practice exam. I used the books and electronic spreadsheet (without using the search features) during this practice exam, and also did not use Google or other references. During the practice exam, I specifically turn on the ability to see explanations of all answers, rather than just the ones I miss (sometimes I may guess and get it right, but not be sure why!). If something is missing from my index, I’ll write down the topic or term quick. In the end, I scored 90% on the first practice with about 10 minutes to spare.

After that, I intended to do an actual read through of the material as well as listen to the mp3 audio of the course (given by the other author!). I only did about day 1 on both of those and decided to forgo those steps in my process. I took the second practice exam just like the first one, and scored 90%. After that, I sent my index off to be printed. Until exam day (about a 2 week gap), my only studying was just occasionally opening the books to flip through the topics and keep the layout and topics somewhat fresh in mind

Alternate material. Now, not everyone can afford SANS courses, but the information in SEC542 can actually be very easily gotten from other sources.

For practical lab-like experience, work on things like DVWA, Mutillidae (both of these were heavily used in the course labs), and OWASP Juice Shop. In addition, every attack can be found somewhere in the HTB boxes (ask someone who’s popped most of the boxes if they can guide you to good candidates, or browse IppSec’s YouTube videos and sample each one for web app opportunities). If you’re lucky enough to have access, the PWK labs also have plenty of web app practice available. Between all of those items, you should be exposed to every attack in this course and beyond.

On the tools, it really absolutely helps to have some Burp exposure and some Python exposure. I actually really recommend courses on PluralSight for both topics. There is a course or two by Sunny Wear going over how to use Burp that is just awesome. And there are a few beginner Python courses as well that helped me quite a bit to get started. (If you do pick up a sub to PluralSight, it also has decent courses on many of these web attacks, too, by Dawid Czagan and Troy Hunt.)

Everything I know about ZAP came from this material, and I suspect just a 20-minute video on ZAP examples would cover it well enough. I just don’t have any particular ones to list here. Of all the topics, I’d have to say web fuzzing is the hardest topic to pick up on one’s own.

For other tools, exposure in the course is light, so just using sqlmap or nikto or recon-ng or nmap or wpscan or beef somewhere on some target is probably good enough to understand it enough. For Python, focus on understanding the basics of Python and then also the requests library.

For attacks, just go through the syllabus and the OWASP 2017 Top 10 web flaws. This course pretty much sticks to that list. Do know how to find and perform Shellshock and Heartbleed attacks, though. (HTB has those boxes!)

Otherwise, just go through the course syllabus and the exam topics item by item until you feel comfortable talking about them and their differences

One thing the course doesn’t go over much at all is source code analysis, but pretty much everything in the labs is open source (umm, you control the VM!), so an enterprising student could look at the flawed code on their own. This is probably a step I need to incorporate as I look at further practice.

After all of that, honestly, you don’t need the course anymore! (But let’s face it, the extra advice from the instructor, the full coverage on the topics, and meeting other professionals in person adds to the course value.)

My next steps. After GWAPT, my next steps on the web application attacking front is to gain more casual experience through practice via self-study on DVWA, Mutillidea, OWASP Juice Shop, and others. I want to particularly make a point to use various tools for the attacks, rather than sticking to just one. And I also want to make sure I can do things manually or with Python scripts when appropriate, and review source code whenever I can for practice identifying flaws (and maybe fixing them?). I have a sub to Pentester Academy which also has extensive web hacking tracks

Will I take SEC642? What about AWAE from Offfensive Security? Maybe, but SANS will entirely depend on whether my employer wants to support me in that next step, and I may be able to swing AWAE on my own if I can carve out that time.

Will I get to any of these this year? I do have other goals and things for this year, but the continued self-study is one I want to stick to. I don’t today do web assessments for internal sites at work, but that opportunity may be right around the corner, and I intend to be part of that.