Hell yea! The new podcast "Brakeing Down Security" will happen on 10 January 2014. Also, I'll have a co-host!
Before you go "Aw hell, ANOTHER security podcast", don't you fret my army of followers. I have been following the "I am the Calvary" mailing list for a while (and if you aren't, you should be), and there is a real need out there for training and awareness. Both those in the IT industry who do it on a daily basis, that maybe don't understand why they are doing what they are doing, or maybe that college student looking to expand her/his knowledge of Information Security and may not have a good place to go.
In the past year or so, I have seen many excellent speakers at the Capital of Texas ISSA chapter, talk about the difficulties of getting people to understand something as simple as password complexity or why we can't have Post-its on our monitors. This podcast is to be for folks like that, so if you're looking for techniques on how to reverse engineer Windows binaries, or creating malware for fun and profit, this won't be your bag. Ideally, I'd like to get up to that point, but that is probably many years in the future.
We are hoping to bring you interviews from people in the industry, people from the Privacy realm, from Healthcare, from Legal, you name it... What we want to show is how vast the industry truly is, so we may have a pentester on one month, and a lawyer specializing in Privacy law next month, or a compliance "check box weasel" the next month (I apologize to all the Compliance Officers out there). We want to do multimedia stuff as well, but just learning the sound editing is gonna be a pain, not even sure how video editing will do.
We're not trying to be the next Pauldotcom or Network Security Podcast (who am I kidding, that'd be awesome!), but we just want to put ourselves out there to be another reference for people who may not want a deep technical discussion.
This is going to be a labor of love, plus, we get CPEs for doing research and preparing for the podcast, so there is a plus in that.
So look here, or on my Twitter feed @bryanbrake, or on my LinkedIn for the post to the podcast. We'll most likely be using LibSyn for hosting, since I've been told by more than one person that they are pretty awesome.
I hope you enjoy it, we definitely want feedback and emails and constructive criticism
Friday, January 3, 2014
Sunday, December 22, 2013
#09: ISSA, name change, macbook networking, data breaches, and the podcast
Yep, the blog name has been changed. I figured that the original title was too wordy, and I'd be stupid not to use my given name... it's just too perfect. So, I registered the domain to point here for the time being, the podcast will also be called 'Brakeing Security'.
It reminds me of the Simpsons episode, probably about 50 years ago, where Homer, Apu, Barney, and Moe were in a barbershop quartet called "The B Sharps". It was funny the first few times, and it gets progressively less funny... It's just like that...
I have decided that I need to stop being one of those guys who sit on the outside of their security organization and say 'Well, I'd have done it like this...'. I have been elected by my peers as the Recording Secretary of the Capital of Texas ISSA chapter. I still don't understand the full powers I have, other than, you know... recording meetings/timekeeping, and making sure the rest of the board don't stab each other. Sounds like fun!!!
My Mid-2012 Macbook Retina Pro is unable to access the wireless at work, so I decided that I would re-purpose my Minipwner (TP-703N) travel router to be a wireless AP for my work wireless. It came rooted, so it wasn't that difficult. I had to setup the travel router to allow for it to connect to the wireless AP at the office, get an IP of 192.168.1.x/24, but then turn around and forward packets to/from my Macbook Retina.
(generated using draw.io)
With all the info on the OpenWRT site, much of it is not updated, or is found in other spots all over the website. The best info I was able to get all in one place was the "Routed Client" using MASQUERADE (http://wiki.openwrt.org/doc/recipes/routedclient#using.masquerade)
Well, after a few issues, mainly that they use newer 'iw' Linux commands, but other than most everything is the same. My Macbook connects with a static 192.168.2.x address, and everything just works.
The real shame is that I had to sacrifice my MiniPwner to do it. It's a USB bus powered, which is nice, because it's small, and a portable battery pack will last days if you aren't plugging it directly into the PC/Laptop. I was using it for a Kismet capture device, as well as doing some reverse SSH tunneling on the inside of our network back to my house, just to try it.
Nowadays, there's PwnPlug, Pineapples, and even Raspberry Pi running Kali to use these days. The best thing about them is: They are very small, and you can hide them in out of the way places to attack networks, assuming you can get into an out of the way place in the business you are attempting to pentest.
In the past few weeks, we've heard about major data breaches, both from JP Morgan Chase (link), and then the uber heist of 40 million cards from Target (link). It really stops and gives me pause, cause any person in Information Security should be wondering 'When is my company next?' or worse 'Is my company already compromised, and I don't know it?' What can be done? IDS? log file analysis? firewall audits looking for connectivity no longer needed? Are proper methods and processes in place to keep unauthorized connections from occurring? The answer is all of this and more. Your organization must want to be secure. Forcing it on them like an older brother scaring your kid brother is only going to breed resentment down the line. And if you suffer from chronic PCI requirements, it's the same thing.
Martin McKeay made a point that I did not realize previously...
It is unfortunate in our day and age, that we can do very little to fix the issue, and companies will still make out better than they were previously. Is it because stock traders believe that they've learned their lesson, and it will never happen again? Target and JP Morgan will survive, lick their wounds, and suffer no long lasting effects, until it happens again. Companies should be made to suffer fines or perhaps additional scrutiny from the SEC when they do their yearly filings. At a minimum, they should sign up all cards with fraud protection, instead of being an opt-in. This would be costly for the orgs involved, because very few people opt-in to the fraud protection offered to them, but by not doing so, they are showing that they care very little for the security mess that they themselves have caused.
The new podcast "Brakeing Security" will start the week of January 6th. I hope to have interviews, at least once a month (hopefully made up of Speakers from our ISSA meeting). I want it to be no more than 30 minutes. I don't have a PhD in sound editing, so it's gonna be a bit rough to start out. I'm hoping to do a little bit of news, some opinion, technical segments, and an interview if I can scrounge one up.
My idea is that there is enough IS/Privacy/Security/Healthcare talent in the Austin area that I should be able to gain an audience from someone anyone.
If you are interested in doing an interview, or have a topic you'd like to talk about on 'Brakeing Security', I would like for you to contact me at 'brakeb@gmail.com' with a subject of "Brakeing Security", and we'll get together and talk about it. I'm pretty democratic, as the 10 domains of CISSP cover a vast amount of IS/IT and Regulatory items, if we can put a security bent on it, we can talk about it. If you have a technical segment about a new security tool that you may be developing, or you are speaking at a convention soon, I'd be greatly pleased to have you on my podcast.
Have a great holiday and remember, tear up the boxes with all the TVs, Xbox, Laptops, etc. Don't just put them out by the trash. People don't need a reason to want to get into your house...
It reminds me of the Simpsons episode, probably about 50 years ago, where Homer, Apu, Barney, and Moe were in a barbershop quartet called "The B Sharps". It was funny the first few times, and it gets progressively less funny... It's just like that...
I have decided that I need to stop being one of those guys who sit on the outside of their security organization and say 'Well, I'd have done it like this...'. I have been elected by my peers as the Recording Secretary of the Capital of Texas ISSA chapter. I still don't understand the full powers I have, other than, you know... recording meetings/timekeeping, and making sure the rest of the board don't stab each other. Sounds like fun!!!
My Mid-2012 Macbook Retina Pro is unable to access the wireless at work, so I decided that I would re-purpose my Minipwner (TP-703N) travel router to be a wireless AP for my work wireless. It came rooted, so it wasn't that difficult. I had to setup the travel router to allow for it to connect to the wireless AP at the office, get an IP of 192.168.1.x/24, but then turn around and forward packets to/from my Macbook Retina.
With all the info on the OpenWRT site, much of it is not updated, or is found in other spots all over the website. The best info I was able to get all in one place was the "Routed Client" using MASQUERADE (http://wiki.openwrt.org/doc/recipes/routedclient#using.masquerade)
Well, after a few issues, mainly that they use newer 'iw' Linux commands, but other than most everything is the same. My Macbook connects with a static 192.168.2.x address, and everything just works.
The real shame is that I had to sacrifice my MiniPwner to do it. It's a USB bus powered, which is nice, because it's small, and a portable battery pack will last days if you aren't plugging it directly into the PC/Laptop. I was using it for a Kismet capture device, as well as doing some reverse SSH tunneling on the inside of our network back to my house, just to try it.
Nowadays, there's PwnPlug, Pineapples, and even Raspberry Pi running Kali to use these days. The best thing about them is: They are very small, and you can hide them in out of the way places to attack networks, assuming you can get into an out of the way place in the business you are attempting to pentest.
In the past few weeks, we've heard about major data breaches, both from JP Morgan Chase (link), and then the uber heist of 40 million cards from Target (link). It really stops and gives me pause, cause any person in Information Security should be wondering 'When is my company next?' or worse 'Is my company already compromised, and I don't know it?' What can be done? IDS? log file analysis? firewall audits looking for connectivity no longer needed? Are proper methods and processes in place to keep unauthorized connections from occurring? The answer is all of this and more. Your organization must want to be secure. Forcing it on them like an older brother scaring your kid brother is only going to breed resentment down the line. And if you suffer from chronic PCI requirements, it's the same thing.
Martin McKeay made a point that I did not realize previously...
It is unfortunate in our day and age, that we can do very little to fix the issue, and companies will still make out better than they were previously. Is it because stock traders believe that they've learned their lesson, and it will never happen again? Target and JP Morgan will survive, lick their wounds, and suffer no long lasting effects, until it happens again. Companies should be made to suffer fines or perhaps additional scrutiny from the SEC when they do their yearly filings. At a minimum, they should sign up all cards with fraud protection, instead of being an opt-in. This would be costly for the orgs involved, because very few people opt-in to the fraud protection offered to them, but by not doing so, they are showing that they care very little for the security mess that they themselves have caused.
The new podcast "Brakeing Security" will start the week of January 6th. I hope to have interviews, at least once a month (hopefully made up of Speakers from our ISSA meeting). I want it to be no more than 30 minutes. I don't have a PhD in sound editing, so it's gonna be a bit rough to start out. I'm hoping to do a little bit of news, some opinion, technical segments, and an interview if I can scrounge one up.
My idea is that there is enough IS/Privacy/Security/Healthcare talent in the Austin area that I should be able to gain an audience from someone anyone.
If you are interested in doing an interview, or have a topic you'd like to talk about on 'Brakeing Security', I would like for you to contact me at 'brakeb@gmail.com' with a subject of "Brakeing Security", and we'll get together and talk about it. I'm pretty democratic, as the 10 domains of CISSP cover a vast amount of IS/IT and Regulatory items, if we can put a security bent on it, we can talk about it. If you have a technical segment about a new security tool that you may be developing, or you are speaking at a convention soon, I'd be greatly pleased to have you on my podcast.
Have a great holiday and remember, tear up the boxes with all the TVs, Xbox, Laptops, etc. Don't just put them out by the trash. People don't need a reason to want to get into your house...
Monday, November 18, 2013
#08: France, CERN, and physical/personal security, and everything else
245 pageviews?! What the hell? I leave for holiday and come back, and it blows up! Welcome to any new readers!! I promise to not disappoint. :D
I have been gone on holiday with my cruise group last month. I had the utmost pleasure to visit the European Center for Nuclear Research or CERN. This trip was one memory that will stick my mind for as long as I live. Not just seeing the incredibly massive 15m long, 40 tonne (all Metric baby!) superconducting segments that ran the entire 17Km length of the LHC, but we also got to take an unexpected trip to the CMS, which was one of the two experiments that found enough sigma to confirm the Higgs Boson. If you're interested, the Major Technicality podcast (@majortechnicality, or www.facebook.com/majortechnicality) will have it posted very soon.
One thing I did want to mention about my trip to CERN was the security controls in place. Much of the main campus in Geneva was open, and they gave us pretty much carte blanche to visit the hallways, but to be quiet about it. I was so enamored by the pure science of what was going on that I did not give the idea of physical or personal much of a thought.
There were no cameras, no access badges. Offices had locks, but the main campus appeared to be a recycled building from before the Cold War and the office sizes definitely had that feel. I believed that everyone I looked in on as I walked by their office was comtemplating the very nature of the universe, or examining data to find that one thing, the one iota of information that would get them the next Nobel. I hope I was not wrong. Fantastic place.
My point was that a 'college' town like Geneva was incredibly "American" in it's attitudes. Young people with their heads in their mobile devices (more Android than Apple oddly enough), and it just felt different, but no less safe. I still carried my wallet in my front pocket, as I do in America, only out of habit. I enjoyed the airports. No TSA, no body scanners... but in place of that, gentlemen with automatic rifles and paramilitary gear patrolled the airport. It's interesting, we've spent billions of dollars "securing" our airports, inventing the DHS and TSA, when in fact, they are spending a fraction of that amount in Europe, and are arguably just as safe or safer even...
The heaviest security I saw was at the ATLAS project. Cameras everywhere, badge access everywhere, including in the elevator, and the area just before you got into the experiment required an iris scan to get into the heart of of the machine. And the area with the iris scanner had a revolving door man trap operated by the control room. When I asked our guide, who's name was 'Gerd' (hey Gerd!!!) he said that was to ensure that only necessary people could access the area, but also to protect people from the high energy radiation that gets kicked out by the ATLAS experiment.
I guess when we think of physical security, we often use it as a term to keep people out of sensitive areas, but security can be used as a protective mechanism, which I don't see that all that often.
Wireless security... Holy cow, I could not believe all the easy access to WPS enabled wifi. If I lived in Geneva or Paris, I never would have needed to have bought Internet access. Dozens of WPS enabled Wifi that could be easily cracked by Reaver. All I needed was a few hours, and I'd have free, unfettered Internet. Which would have been a damn sight better than what we did have when we were able. Hotels charge a lot for wifi, and my Verizon International data failed. I need to get a hold of a good overseas phone that will at least allow me to access Google Maps... But we travel over there so infrequently, doesn't really make much sense...
Well, now that I'm back from holiday, I really want to make this podcast deal happen. Yes, I know everyone seems to have one, and "What's gonna make your podcast awesomer than everyone elses?" Simple truth: it won't be. I'm learning. Hell, learning security is hard, but to learn rudimentary sound (video?) editing, as well as the bells and whistles of content creation (web page design, advertising/marketing, setup of interviews, etc) will be the real challenge. Sitting down, spitting drivel into a microphone is easy. I mean, look at all the talking heads on TV... I'm at least 80% smarter than those people. I just want to do a simple 30-40 minutes once a week (twice if I'm lucky), something really off the cuff, some security stories, and talk about security concepts I'm working on. I'm dabbling with Python, and reading the Metasploit book written by @HackingDave (Dave Kennedy) and others, as well as doing my Pentester Academy stuff. It's a full life. But I would really like to do something that is mine. I listen to enough podcasts that I realize I can't do much worse than the other folks. And besides, even if no one listens, I'll be doing something I like. I think "Adrift in the Security Sea Podcast" is too wordy. I'll probably need to use an acronym to shorten it... like the A.S.S. Podcast... oh... well, guess that is off the table. Well, it's a work in progress... I found some royalty-free music, worked on an intro... I just need to figure a few other things out...
Oh, went through a great class last Friday that discussed detecting malware in your network. The folks over at @Mi2security, Michael Gough and Ian Robertson, showcased how the creation of a Master File Record, using file hashing, along with their brand new software Sniper Forensics Toolkit to reduce the ability for malware to take hold in a system. It looks very promising, and I am going to try it at my home in the next few days. Going to the class got you a 3 host license to try the software. No Linux client yet, but they are diligently working on that.
Take care, and I'll update this post with the Major Technicality when it gets posted. Take care... And tell your friends.
The heaviest security I saw was at the ATLAS project. Cameras everywhere, badge access everywhere, including in the elevator, and the area just before you got into the experiment required an iris scan to get into the heart of of the machine. And the area with the iris scanner had a revolving door man trap operated by the control room. When I asked our guide, who's name was 'Gerd' (hey Gerd!!!) he said that was to ensure that only necessary people could access the area, but also to protect people from the high energy radiation that gets kicked out by the ATLAS experiment.
I guess when we think of physical security, we often use it as a term to keep people out of sensitive areas, but security can be used as a protective mechanism, which I don't see that all that often.
Wireless security... Holy cow, I could not believe all the easy access to WPS enabled wifi. If I lived in Geneva or Paris, I never would have needed to have bought Internet access. Dozens of WPS enabled Wifi that could be easily cracked by Reaver. All I needed was a few hours, and I'd have free, unfettered Internet. Which would have been a damn sight better than what we did have when we were able. Hotels charge a lot for wifi, and my Verizon International data failed. I need to get a hold of a good overseas phone that will at least allow me to access Google Maps... But we travel over there so infrequently, doesn't really make much sense...
Well, now that I'm back from holiday, I really want to make this podcast deal happen. Yes, I know everyone seems to have one, and "What's gonna make your podcast awesomer than everyone elses?" Simple truth: it won't be. I'm learning. Hell, learning security is hard, but to learn rudimentary sound (video?) editing, as well as the bells and whistles of content creation (web page design, advertising/marketing, setup of interviews, etc) will be the real challenge. Sitting down, spitting drivel into a microphone is easy. I mean, look at all the talking heads on TV... I'm at least 80% smarter than those people. I just want to do a simple 30-40 minutes once a week (twice if I'm lucky), something really off the cuff, some security stories, and talk about security concepts I'm working on. I'm dabbling with Python, and reading the Metasploit book written by @HackingDave (Dave Kennedy) and others, as well as doing my Pentester Academy stuff. It's a full life. But I would really like to do something that is mine. I listen to enough podcasts that I realize I can't do much worse than the other folks. And besides, even if no one listens, I'll be doing something I like. I think "Adrift in the Security Sea Podcast" is too wordy. I'll probably need to use an acronym to shorten it... like the A.S.S. Podcast... oh... well, guess that is off the table. Well, it's a work in progress... I found some royalty-free music, worked on an intro... I just need to figure a few other things out...
Oh, went through a great class last Friday that discussed detecting malware in your network. The folks over at @Mi2security, Michael Gough and Ian Robertson, showcased how the creation of a Master File Record, using file hashing, along with their brand new software Sniper Forensics Toolkit to reduce the ability for malware to take hold in a system. It looks very promising, and I am going to try it at my home in the next few days. Going to the class got you a 3 host license to try the software. No Linux client yet, but they are diligently working on that.
Take care, and I'll update this post with the Major Technicality when it gets posted. Take care... And tell your friends.
Thursday, October 10, 2013
#07: Interpreting frameworks... or 'the second opinion'
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...
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, 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...
Subscribe to:
Comments (Atom)