I published a lot of information about my class slides and lab materials in these other posts. In this post I’ll tell you how to get the related class lab code, with some caveats. But first, please read these posts and check out the other materials:
In those posts I explain the various ways in which someone tried to sabotage my classes. It was obvious that someone was trying to get into the class code and materials and was testing my portal and repositories.
I once heard a student joke about how another large security training organization gives students a “sketchy thumb drive.” I don’t know if they still do. Thumb drives have one advantage. They are not connected to any network so they can’t be targeted and compromised over the network during a class. Though if they have been compromised during production you could have other problems. If you insert one into your computer your risk installing any malware on that drive.
In my case, I was teaching a cloud security class so it made no sense to hand out a thumb drive. To minimize the risk associated with someone targeting the class resources (which they did), I set up separate infrastructure for each class. That way, if one class was compromised others were not affected.
I explain some ways students or someone tried to mess up things I was using in class and how I worked around it in the above posts. And it was always the pentesting lab they went after. Hmm. Who do you think was doing that?
The reality is, some large training organizations have 500 people working for them (or they did at the time). I was one person. I didn’t have time to invest on completely building a secure portal, testing, and monitoring everything students were doing on my network during class at the same time I was teaching. So this was my approach.
When you logged into my portal it was really dumb. All it did was give you some links to Google Drive. The actual authentication process was handed by Google to log into Google Drive. If someone wanted to hack that they were going to have to hack Google.
The portal login was equally as dumb. It was pretty open. But what I did was send every single request submitted to that portal for the purposes of getting access to the class materials to AWS CloudWatch. I didn’t process or check anything it was more like a proxy. I picked up the requests from CloudWatch when data was submitted.
That way, if someone wanted to hack my portal submissions - they were going to have to hack AWS, not my code. My code had nothing of value and did nothing. What capturing every request in CloudWatch did for me is allowed me to see every single request submitted from which IP addresses (and thank you to whomever submitted all the attack samples. I appreciate that as a penetration tester.)
The slides, lab materials, and code are out of date but you may be able to still learn things from them as explained in other posts. I do some things in different ways now. Companies are doing things in different ways now. New services exist that did not exist back then. But the fundamentals still hold true today.
You could take these materials and update them and expand upon them. They will give you a solid base for what you need to think about when securing a cloud environment - or any environment for that matter. The cloud platform security fundamentals are still the same - even with AI.
Networking, encryption, IAM, Application Security.
All I ask if you use these materials is a shout out to my blog and social media accounts.
Cloud security lab code:
https://github.com/2ndSightLab/2nd-sight-lab-class
Subscribe for more posts on security and technology research.
— Teri Radichel