It's not everyday you're called into your bosses office with a 30 minute meeting titled 'Quick meeting'. Meetings called that rarely are.
As my colleague and I made our way to our bosses office, my paranoia set off, like any good security professional. What did I do? What did we do? Maybe it's about X or maybe it's about that other meeting yesterday.
Thankfully, it was none of those. Our boss decided in his infinite wisdom, that we'd been remiss in our allowing one person to interpret what the bible, the framework that guides our actions, the PCI-DSS 2.1 framework, says. "We may be misunderstanding certain portions, and what's worse, our relationship with our QSA is not what it should be", he says. "We need to do better, to be better."
Silence... flabbergasted...
We thought that we'd been doing well. Just passed our 3Q PCI milestones, and were working steadily towards implementing controls and policies that we didn't have about certain audits. We were around CMMI Level 2 on many of these things. No formal policy, but we were doing them. We are working towards Level 3, 4, and 5.
So, why the re-evaluation? Our compliance person has one idea of what PCI means, but after speaking with our QSA's superiors, we found that we may have been farther along in the PCI process than we thought.
For example, We went from 'all firewall ACLs had to be justified' to 'We must be doing regular audits on firewall logs' Which we had been doing that nearly everyday for the last 6 months. What a pain in the ass to find out that we have been good to go. We still plan on finding out how what is connecting to our networks, and why.
Compliance is a funny thing. It's a gray area that I am not accustomed to. It's 'check-box' security. Security != Compliance, and yet making sure we are at the 'low common denominator' of security is what we do.
Now that we have some breathing room, we are finding that the 'compliance' marathon is helping us find more security related tasks that we can take ourselves beyond PCI compliance. Which is what should be strived for... beyond compliance. Some of our firewall ACLs are years old. Are they still needed? Who uses them? What's the hitcount on them? We have revised our policies to say that anything more than 90 days old without a change in hitcount is going to put the ACL in a 'reviewable' status, and if there has been no change in 120 days, we will remove them.
If you haven't had a look at what is coming in and out of your environment, or even between your network segments, I think you should re-consider. You may even find that white whale of issues, the dreaded 'any-any' rule... *shudders* Gives me nightmares, especially if it's been in there for a while.
I am hoping to start some interactive content on my site soon. I would like to go in the direction of securitytube, but maybe in a compliance bent. Going over various compliance frameworks, methodologies, even get in the weeds with items like Meaningful Use for securing medical records. Maybe like what Vivek does for Metasploit, for his megaprimers...
Any who, that won't happen until after I get back from my holiday... Take care, and hope you like what you see...
Thursday, October 10, 2013
Thursday, September 26, 2013
#06: 'Checkbox security', and security tube, and milestones
<rant> I am so tired of hearing 'checkbox security'. For me, that term means we aren't doing enough, and just trying to get by. When I was in the Navy, you could just get by just doing the minimum, and people notice. Were there days when I felt like doing the minimum? Heck yes, but not when it came to my job protecting my network.
I need to switch that term back to what it should be called... 'Compliance'. COMPLIANCE !== SECURITY. It's the bare minimum to start with if you want security. Or at least be more secure. I'm tired of just getting by doing the minimum, and I'm gonna change that next week. I'm gonna rise up and make some shit happen.
</rant>
I finished with the excellent C|EH All-in-one book, written by Matt Walker (ISBN: 978-0-07-177228-0). If you're a n00b to the arena of ethical hacking and pentesting, like me, then you'll want to check this book out, especially if you're working toward getting your C|EH. I was dismayed to find the C|EH test is just another multiple choice test. You regurgitate what you 'know' and pass. Much like the CISSP. I think I am a little confused by how you go about taking the exam. I've read the All-in-One, did fairly well on the practice tests in the back, and have attended a week-long ethical hacking course given by our local ISSA chapter. Plus, there are tons of practice tests and questions that are free on the Internet. Guess I just need to sit down, fill out the form and take the exam.
Now that I'm done reading the CEH book, I've started in earnest on learning Python. Using the excellent 'Wood Rat' (Neotoma Muridae) book from O'Reilly, I usually read at night as I am going to bed. I can usually knock out about 10-12 pages a night. To augment this, I saw that Vivek Ramachandran over at SecurityTube (http://www.securitytube.net/) has started the "Pentester Academy" which allows you to take advantage of all of his excellent video training. I have started the "Securitytube Python Scripting Expert" megaprimer/track that has Vivek explaining concepts like tuples, immutable strings, and if/when type loops. The loops are nothing new, but I've not worked with scripting to the level I am about to learn with this. Python is a freaking powerful language, and very VERY flexible.
I initally balked at the cost. It's $99 for the first month, plus $39/month thereafter. But I figure with the book I'm reading and this, I can learn a lot. Vivek does a good job of explaining concepts and I am fairly confident that I can/will learn Python using him and the O'Reilly book as an augment to the training. You can find Vivek on Twitter @securitytube. He doesn't pay me to say any of this, and his site really has a lot of great content, even Metasploit training. And I heard on last week's Pauldotcom security weekly podcast that he is working on a Burp Suite series, which I'm highly excited about. You can find his interview with @pauldotcom here: http://pauldotcom.com/2013/09/episode-346-guest-interview-wi.html
Lastly, we made our PCI milestones this quarter. While I abhor the concept of 'compliance' frameworks, it's nice not to have that 500 pound gorilla on our collective backs, at least for a few days (that gorilla being 'management'). A lot of the stress was learning the processes for submitting reports to Tenable, our new QSA and inital setup of Nessus. If you haven't find a good QSA, or are looking for a good vulnerability scanner, Nessus is very easy to learn, and the reporting is nice, concise, and easy to parse, and Tenable's QSA's are very knowledgeable and very efficient at explaining what is needed for the burden of proof.
Thanks for reading this. You might be the only one.
I need to switch that term back to what it should be called... 'Compliance'. COMPLIANCE !== SECURITY. It's the bare minimum to start with if you want security. Or at least be more secure. I'm tired of just getting by doing the minimum, and I'm gonna change that next week. I'm gonna rise up and make some shit happen.
</rant>
I finished with the excellent C|EH All-in-one book, written by Matt Walker (ISBN: 978-0-07-177228-0). If you're a n00b to the arena of ethical hacking and pentesting, like me, then you'll want to check this book out, especially if you're working toward getting your C|EH. I was dismayed to find the C|EH test is just another multiple choice test. You regurgitate what you 'know' and pass. Much like the CISSP. I think I am a little confused by how you go about taking the exam. I've read the All-in-One, did fairly well on the practice tests in the back, and have attended a week-long ethical hacking course given by our local ISSA chapter. Plus, there are tons of practice tests and questions that are free on the Internet. Guess I just need to sit down, fill out the form and take the exam.
Now that I'm done reading the CEH book, I've started in earnest on learning Python. Using the excellent 'Wood Rat' (Neotoma Muridae) book from O'Reilly, I usually read at night as I am going to bed. I can usually knock out about 10-12 pages a night. To augment this, I saw that Vivek Ramachandran over at SecurityTube (http://www.securitytube.net/) has started the "Pentester Academy" which allows you to take advantage of all of his excellent video training. I have started the "Securitytube Python Scripting Expert" megaprimer/track that has Vivek explaining concepts like tuples, immutable strings, and if/when type loops. The loops are nothing new, but I've not worked with scripting to the level I am about to learn with this. Python is a freaking powerful language, and very VERY flexible.
I initally balked at the cost. It's $99 for the first month, plus $39/month thereafter. But I figure with the book I'm reading and this, I can learn a lot. Vivek does a good job of explaining concepts and I am fairly confident that I can/will learn Python using him and the O'Reilly book as an augment to the training. You can find Vivek on Twitter @securitytube. He doesn't pay me to say any of this, and his site really has a lot of great content, even Metasploit training. And I heard on last week's Pauldotcom security weekly podcast that he is working on a Burp Suite series, which I'm highly excited about. You can find his interview with @pauldotcom here: http://pauldotcom.com/2013/09/episode-346-guest-interview-wi.html
Lastly, we made our PCI milestones this quarter. While I abhor the concept of 'compliance' frameworks, it's nice not to have that 500 pound gorilla on our collective backs, at least for a few days (that gorilla being 'management'). A lot of the stress was learning the processes for submitting reports to Tenable, our new QSA and inital setup of Nessus. If you haven't find a good QSA, or are looking for a good vulnerability scanner, Nessus is very easy to learn, and the reporting is nice, concise, and easy to parse, and Tenable's QSA's are very knowledgeable and very efficient at explaining what is needed for the burden of proof.
Thanks for reading this. You might be the only one.
Tuesday, September 17, 2013
#05: The Value of Research...
I had been stumped over the past few days by an issue that came up at work. A configuration issue 'seen' by our vulnerability scanner was making me and my co-worker pull out our hair, not to mention what occurred when it was known by management...
All attempts to use the information found in the methods of remediation supplied by our vuln scanner were less than useful. "Remove $SERVICE from use" "Stop using $Important_piece_of_data", and et cetera. Add to it that the CVE in question was from more than 10 years ago, and you have a recipe for disaster. (You'll forgive me for being vague above, but operational security prevents me from divulging much more than that.)
Now, I pride myself on being pretty good at doing my due diligence in finding out information. I rarely ask questions of things I do not know, because I want to find the answer myself. Google is my wingman usually, and then failing that, I try Bing and Yahoo. Dogpile used to be my search engine of choice back in the day, but most browsers don't have the search plugins for it anymore. I even used one called 'Vivisimo' for a few years, which clustered results from other engines, but I just faded away from it, for whatever reason.
It's amazing that in my quest to become a security professional, what did I find along the way? Pentesters MUST do research if they plan on attacking a target, because all the little breadcrumbs on the Internet can lead to a bigger picture of a person, or company that can be used to attack them. This is right up my alley. By finding out someone went to Purdue, or active on certain forums, that can give you a picture of who they are or what can be used in social engineering attacks
When my work colleague and I went through our pentesting and ethical hacking course, we learned that the Internet makes it super simple, heck, they'll even aggregate that information for you. Pipl.com is a good site for getting info about people, but they only give you certain info (name, DOB, places lived). But there are a grip of sites like this that will give you meta bread crumbs. You learn a woman's maiden name on one site, her address on another, even her phone number and if she's had a bankruptcy on a third. It's all about what information would be the chink in the armor. A bankruptcy? Send him/her an email at work from the 'lawyer' stating that there was a mistake in the judgment, and click on this PDF to read the summary... boom! one payload infected PDF later, and you have shell into their network.
I guess my point is that research is a very good way of getting where you need to go.
Oh yes, my original story... I managed to find a blog (much like my own) that talked about a program that I could use to test my appliance. Thankfully, it was already in my Kali Linux distro. After reading a bit of the help and man pages, I was able to query my appliance with it. I was pleasantly surprised to find that we were in fact not running what setting the vuln scanner suggested. So after agonizing over this issue, and getting management in a tizzy, we may be able to laugh this off over a couple of beers in a week or so...
So, next time you're asking yourself, "What's the capital of Swaziland**?" Get into the habit of grabbing your browser and doing your research. You'll find out on your own, which gives you a sense of empowerment, and you can leverage the various search engines to make your job easier.
Until next time...
**Swaziland, a country completely surrounded by South Africa, and Mozambique, has two capitals, Lobamba, the royal and legislative capital, and Mbabane, the administrative capital. And you thought you wouldn't learn anything here today.
All attempts to use the information found in the methods of remediation supplied by our vuln scanner were less than useful. "Remove $SERVICE from use" "Stop using $Important_piece_of_data", and et cetera. Add to it that the CVE in question was from more than 10 years ago, and you have a recipe for disaster. (You'll forgive me for being vague above, but operational security prevents me from divulging much more than that.)
Now, I pride myself on being pretty good at doing my due diligence in finding out information. I rarely ask questions of things I do not know, because I want to find the answer myself. Google is my wingman usually, and then failing that, I try Bing and Yahoo. Dogpile used to be my search engine of choice back in the day, but most browsers don't have the search plugins for it anymore. I even used one called 'Vivisimo' for a few years, which clustered results from other engines, but I just faded away from it, for whatever reason.
It's amazing that in my quest to become a security professional, what did I find along the way? Pentesters MUST do research if they plan on attacking a target, because all the little breadcrumbs on the Internet can lead to a bigger picture of a person, or company that can be used to attack them. This is right up my alley. By finding out someone went to Purdue, or active on certain forums, that can give you a picture of who they are or what can be used in social engineering attacks
When my work colleague and I went through our pentesting and ethical hacking course, we learned that the Internet makes it super simple, heck, they'll even aggregate that information for you. Pipl.com is a good site for getting info about people, but they only give you certain info (name, DOB, places lived). But there are a grip of sites like this that will give you meta bread crumbs. You learn a woman's maiden name on one site, her address on another, even her phone number and if she's had a bankruptcy on a third. It's all about what information would be the chink in the armor. A bankruptcy? Send him/her an email at work from the 'lawyer' stating that there was a mistake in the judgment, and click on this PDF to read the summary... boom! one payload infected PDF later, and you have shell into their network.
I guess my point is that research is a very good way of getting where you need to go.
Oh yes, my original story... I managed to find a blog (much like my own) that talked about a program that I could use to test my appliance. Thankfully, it was already in my Kali Linux distro. After reading a bit of the help and man pages, I was able to query my appliance with it. I was pleasantly surprised to find that we were in fact not running what setting the vuln scanner suggested. So after agonizing over this issue, and getting management in a tizzy, we may be able to laugh this off over a couple of beers in a week or so...
So, next time you're asking yourself, "What's the capital of Swaziland**?" Get into the habit of grabbing your browser and doing your research. You'll find out on your own, which gives you a sense of empowerment, and you can leverage the various search engines to make your job easier.
Until next time...
**Swaziland, a country completely surrounded by South Africa, and Mozambique, has two capitals, Lobamba, the royal and legislative capital, and Mbabane, the administrative capital. And you thought you wouldn't learn anything here today.
Saturday, September 7, 2013
#04: ... of nonces and mushrooms
We have been doing updates with regard to our web applications at work this week. Deploying a more randomized token for our Tomcat applications.
A nonce is a random or pseudo-random token that is generated by the server when doing authentication to reduce the chance of replay attacks, like Cross Site Request Forgery and Session Fixation. It's important that our clients, who are not technologically savvy, to be as protected as possible from replay attacks.
Also, as the discoverer of the issue on our application servers, I failed to understand that just because they have a dog in the fight, that they should be brought to the fight. There are just some people that hinder the incident response and they will do what they think is the 'proper' way to do it.
This has given me the idea that a proper incident response plan is more necessary that ever before... Every person knows their place in the process, and there is a proper level of escalation, and certain conditions must be met to reach a new escalation point. I failed in that respect, and wished that I had not invited everyone to the incident. After this, I will definitely do a lessons learned with management and draft a better incident response plan. Some people in the org just need to be mushrooms. Keep them in the dark... They are happier that way.
All in all, an odd couple of weeks. My plan next week is to school our testers and developers on using web security frameworks that will enhance our web applications. Cause we want to have a more secure environment before they deploy. We'll also be giving them a vuln scanner they can use to check against for possible future patching. And also showing them Burp Suite so they can test against various inputs to check for XSS and other OWASP issues, like SQLI...
It's hard to believe how far this organization has come from a couple of years ago...
A nonce is a random or pseudo-random token that is generated by the server when doing authentication to reduce the chance of replay attacks, like Cross Site Request Forgery and Session Fixation. It's important that our clients, who are not technologically savvy, to be as protected as possible from replay attacks.
Also, as the discoverer of the issue on our application servers, I failed to understand that just because they have a dog in the fight, that they should be brought to the fight. There are just some people that hinder the incident response and they will do what they think is the 'proper' way to do it.
This has given me the idea that a proper incident response plan is more necessary that ever before... Every person knows their place in the process, and there is a proper level of escalation, and certain conditions must be met to reach a new escalation point. I failed in that respect, and wished that I had not invited everyone to the incident. After this, I will definitely do a lessons learned with management and draft a better incident response plan. Some people in the org just need to be mushrooms. Keep them in the dark... They are happier that way.
All in all, an odd couple of weeks. My plan next week is to school our testers and developers on using web security frameworks that will enhance our web applications. Cause we want to have a more secure environment before they deploy. We'll also be giving them a vuln scanner they can use to check against for possible future patching. And also showing them Burp Suite so they can test against various inputs to check for XSS and other OWASP issues, like SQLI...
It's hard to believe how far this organization has come from a couple of years ago...
Saturday, August 24, 2013
#03: XSS, Session fixation, and input sanitization
Holy cow, it's been a busy week. Who would have thought moving to a new vulnerability scanner would cause all kinds of issues. What kills me about the number of vuln scanners I've used in the past is that all of them have their own findings, and none of them find everything. Retina, Nessus, OpenVAS, Critical Watch... all of them detect their own little things. Some are better at finding OWASP issues, others are better at OS-level detection. All of them suck at detection, but then, they can only do so much.
One of the major findings was multiple XSS errors. That was easy enough to fix, developers just had to be mobilized to fix the issues. Santize that input!!!!
The issue is with testing. I'm not what you might call 'savvy' with all the OWASP issues. Cross Site Scripting, Request Forgery, Session Fixation... I have gone from 'things I hear on a podcast' to knowing how they work to now using specific tools that allow me to test for them.
My tools of choice in the last year has been Burp Suite. I love it. A lot... Not only do you get a powerful tool to show exactly what internet connections are going across (if you're using the 'Interceptor'), but if you've changed the Internet Explorer proxy settings, you can modify the HTTP connections BEFORE they are shipped back to the server, or change the incoming request from the server. Add to that Burp Suite is free, and you have a tool that you should carry with you on a flash drive. Burp Suite runs in Java, so that is the only dependency.
I find that I get better results testing XSS with Internet Explorer, because it's easier to disable the XSS protections. There are ways to do it in Chrome, but a radio button in IE is just easier. Also, we test for clients and what the lowest common denominator would use, and that is still unfortunately Windows, and Internet Explorer.
I am also looking at Cookie Flags, which are another method of reducing XSS attacks. Next week, matter of fact, I will be testing as to whether the flags have been correctly set when visiting certain websites. You can use Burp for this, but I have found the easiest method is to find a plugin, like "Edit This Cookie" to show you the flags.
This is just an example above. According to OWASP, Setting the "Secure" flag and the "HTTPOnly" flags tells the site what cookies will be transmitted and when. This tells the browser to transmit a cookie when encrypted communications is required, or in the case of this cookie, whenever HTTP traffic is generated. This means both HTTP and HTTPS. 'HTTPOnly' is not the opposite of 'Secure'.
For me to test, it's as easy as visiting the site, and clicking on the icon. I can also set the cookie flags if I want to. This can be good for testing web applications that set multiple cookies... you can even break a site I'd imagine.
I've only scratched the surface with Burp Suite. One thing I did have an issue with, and believe me, it's NOT an issue. When using Chrome 29 with Burp, I found that I could not do Google searches with burp Suite on... Chrome complains that the site SSL certificate doesn't match. That is fantastic! Even with the intercept set to 'Off', Chrome will not allow someone to surf Google with a fake cert. IE isn't so kind. I'm able to do everything I need to do, even Google Searches.
There are others, like Parosproxy, but I've been happy using Burp Suite. I may try to get our organization to buy a license. There isn't a need to, because for what I'm using it for is available on the free model. I just think that good software should get supported. And if I can socially engineer my boss into giving them some beer money, then I've done my good deed for the day.
One of the major findings was multiple XSS errors. That was easy enough to fix, developers just had to be mobilized to fix the issues. Santize that input!!!!
The issue is with testing. I'm not what you might call 'savvy' with all the OWASP issues. Cross Site Scripting, Request Forgery, Session Fixation... I have gone from 'things I hear on a podcast' to knowing how they work to now using specific tools that allow me to test for them.
My tools of choice in the last year has been Burp Suite. I love it. A lot... Not only do you get a powerful tool to show exactly what internet connections are going across (if you're using the 'Interceptor'), but if you've changed the Internet Explorer proxy settings, you can modify the HTTP connections BEFORE they are shipped back to the server, or change the incoming request from the server. Add to that Burp Suite is free, and you have a tool that you should carry with you on a flash drive. Burp Suite runs in Java, so that is the only dependency.
I find that I get better results testing XSS with Internet Explorer, because it's easier to disable the XSS protections. There are ways to do it in Chrome, but a radio button in IE is just easier. Also, we test for clients and what the lowest common denominator would use, and that is still unfortunately Windows, and Internet Explorer.
I am also looking at Cookie Flags, which are another method of reducing XSS attacks. Next week, matter of fact, I will be testing as to whether the flags have been correctly set when visiting certain websites. You can use Burp for this, but I have found the easiest method is to find a plugin, like "Edit This Cookie" to show you the flags.
This is just an example above. According to OWASP, Setting the "Secure" flag and the "HTTPOnly" flags tells the site what cookies will be transmitted and when. This tells the browser to transmit a cookie when encrypted communications is required, or in the case of this cookie, whenever HTTP traffic is generated. This means both HTTP and HTTPS. 'HTTPOnly' is not the opposite of 'Secure'.
For me to test, it's as easy as visiting the site, and clicking on the icon. I can also set the cookie flags if I want to. This can be good for testing web applications that set multiple cookies... you can even break a site I'd imagine.
I've only scratched the surface with Burp Suite. One thing I did have an issue with, and believe me, it's NOT an issue. When using Chrome 29 with Burp, I found that I could not do Google searches with burp Suite on... Chrome complains that the site SSL certificate doesn't match. That is fantastic! Even with the intercept set to 'Off', Chrome will not allow someone to surf Google with a fake cert. IE isn't so kind. I'm able to do everything I need to do, even Google Searches.
There are others, like Parosproxy, but I've been happy using Burp Suite. I may try to get our organization to buy a license. There isn't a need to, because for what I'm using it for is available on the free model. I just think that good software should get supported. And if I can socially engineer my boss into giving them some beer money, then I've done my good deed for the day.
Sunday, August 18, 2013
#02: Vulscan and Nmap
While searching around on the Internet, it is amazing the things you'll find. Nmap's ability to run custom scripts is a very powerful tool.
Vulscan, found at http://www.computec.ch/projekte/vulscan/ can be used in conjunction with Nmap as a 'poor man's Nessus' for a lack of better terms. Using Nmap's operating system guess algorithms, you can then follow certain vulnerability databases, like OSVDB, CVE, and ExploitDB. So far, I have tested this with a couple of servers at work... but unfortunately, the servers are web sites, and for some reason, Nmap can't figure out what the OS fingerprint is. I am wondering if the fingerprinting isn't somehow being affected by my router, because it's showing up as...
Sorry for the size... I'm still figuring this "import image" thing out... But I am damn sure we aren't running "Apple embedded" anything at work... So, I thought I would try going through a different Internet connection, that being tethered to my phone.
LOL... it's even worse tethered to my phone. That same webserver that I scanned from my home, now on my phone is saying that it's a "Panasonic Webcam". What the hell? Guess I need to investigate further. More on that later...
I fully intend to continue testing with Vulscan, maybe as a quick vuln scanner. We just bought Nessus at work, and pairing OpenVAS with Vulscan will allow us to catch even more issues than previously.
Vulscan, found at http://www.computec.ch/projekte/vulscan/ can be used in conjunction with Nmap as a 'poor man's Nessus' for a lack of better terms. Using Nmap's operating system guess algorithms, you can then follow certain vulnerability databases, like OSVDB, CVE, and ExploitDB. So far, I have tested this with a couple of servers at work... but unfortunately, the servers are web sites, and for some reason, Nmap can't figure out what the OS fingerprint is. I am wondering if the fingerprinting isn't somehow being affected by my router, because it's showing up as...
 |
| Nmap output from a webserver at work |
Sorry for the size... I'm still figuring this "import image" thing out... But I am damn sure we aren't running "Apple embedded" anything at work... So, I thought I would try going through a different Internet connection, that being tethered to my phone.
LOL... it's even worse tethered to my phone. That same webserver that I scanned from my home, now on my phone is saying that it's a "Panasonic Webcam". What the hell? Guess I need to investigate further. More on that later...
I fully intend to continue testing with Vulscan, maybe as a quick vuln scanner. We just bought Nessus at work, and pairing OpenVAS with Vulscan will allow us to catch even more issues than previously.
Tuesday, August 13, 2013
#01: The tools we use...
**My opinions are not my employers, and thusly are mine and mine alone**
I am slowly coming around to understanding the nature of tools like Metasploit, Nmap, and the like. I thought that to become a security researcher, you have to understand exactly what the underlying code does, and you're required to grow your Unix-y beard and ponytail like everyone else. I felt like Metasploit was a 'cheat' that people used to become pentesters. I have been around long enough to see people get into positions they clearly were not ready for, and earned certifications because they could write a good test, yet had no knowledge of what they were doing.
I equate Metasploit to the blender a chef would use in a kitchen. It's a tool, that automates a process that is time consuming or laborious. Or a wrench that a mechanic would use to tighten bolts. Everyone in a job has their tools, those little time savers that make work more efficient. Someone else created the blender, and the wrench, but we gain an advantage by using them.
I always thought that I'd need to make my own exploits and learn C and Assembly, and I'd need to learn how to solder well enough to make my own circuits for hardware malware, etc. While I would still love to have an in-depth knowledge of those ideas, I have realized that I ended up with a bit of scope creep, and that I need to dial it back a bit to keep from being overwhelmed.
That's why I'm learning Python, and someone else suggested Ruby (since Metasploit uses that)... I do want to learn more about C, but right now, I just have the basics. Plus, there isn't much in the way of C programming being used at my office, so I need to learn concepts that will relate directly to my job so I can keep my edge sharp...
So, Python and Ruby it is... Also, gotta get back to shell scripting... I used to do it a lot in the past, but vulnerability scanning, and justification of firewall ACLs for PCI-DSS doesn't have a place for shell scripting...
I want to do a post once a week, even if it's just stream of consciousness shit. The C|EH All-in-One book is a hard slog though... Just through the chapter on Social Engineering. I realize now that we probably should give some kind of training on a regular basis to spot social engineering trickery, as well as proper disposal of papers with info on them... ooh... I wonder how difficult the shred bins locks are to pick... Yep, even when you reduce scope, scope creeps back...
I am slowly coming around to understanding the nature of tools like Metasploit, Nmap, and the like. I thought that to become a security researcher, you have to understand exactly what the underlying code does, and you're required to grow your Unix-y beard and ponytail like everyone else. I felt like Metasploit was a 'cheat' that people used to become pentesters. I have been around long enough to see people get into positions they clearly were not ready for, and earned certifications because they could write a good test, yet had no knowledge of what they were doing.
I equate Metasploit to the blender a chef would use in a kitchen. It's a tool, that automates a process that is time consuming or laborious. Or a wrench that a mechanic would use to tighten bolts. Everyone in a job has their tools, those little time savers that make work more efficient. Someone else created the blender, and the wrench, but we gain an advantage by using them.
I always thought that I'd need to make my own exploits and learn C and Assembly, and I'd need to learn how to solder well enough to make my own circuits for hardware malware, etc. While I would still love to have an in-depth knowledge of those ideas, I have realized that I ended up with a bit of scope creep, and that I need to dial it back a bit to keep from being overwhelmed.
That's why I'm learning Python, and someone else suggested Ruby (since Metasploit uses that)... I do want to learn more about C, but right now, I just have the basics. Plus, there isn't much in the way of C programming being used at my office, so I need to learn concepts that will relate directly to my job so I can keep my edge sharp...
So, Python and Ruby it is... Also, gotta get back to shell scripting... I used to do it a lot in the past, but vulnerability scanning, and justification of firewall ACLs for PCI-DSS doesn't have a place for shell scripting...
I want to do a post once a week, even if it's just stream of consciousness shit. The C|EH All-in-One book is a hard slog though... Just through the chapter on Social Engineering. I realize now that we probably should give some kind of training on a regular basis to spot social engineering trickery, as well as proper disposal of papers with info on them... ooh... I wonder how difficult the shred bins locks are to pick... Yep, even when you reduce scope, scope creeps back...
Subscribe to:
Posts (Atom)