#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...

#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.

#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...

#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.

#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.

#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...

#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.

#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...

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.

#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...

#00: the beginning

**My opinions are my own, and not of my employer**

I started this blog to help me to put down somewhere things that I am learning about with regard to security and things that interest me in the field of Security.  I don't want to say I'm an "Information Security Professional"... it's too constricting.  I mean, if you look out there, there is a whole world of security concepts and tasks, and you'd be hard pressed not to find something in there that doesn't tickle your fancy.

Security researchers these days are getting into all kinds things.  It used to be that networks (wireless or wired), servers and workstations, or databases were the only gems to exploit.  But in recent years, researchers like the late, great Barnaby Jack and others have been looking at SCADA systems, vehicles, medical devices, etc for security vulnerabilities. And let's not forget the whole mobile platform.  Tablets, phones, mini-PCs, all run a varied operating system with a user base that suffers from either lack of knowledge, or they don't want to know.

I got into security late into the game.  Sure, I've been doing it my entire career, whether that be Physical Security (access controls to COMSEC), or Network Security (typical IT admin stuff).  All the way up to what I'm doing with my current job, which is compliance, governance, and attempting to wrest control of the network out of the hands of users who just want to do what they feel is necessary to get the job done.

I want to start this blog to highlight my continuing journey across the Security "Sea".  It's vast, it's fraught with difficulties, and the metaphorical boat I'm riding on has holes in it, or tigers even (nod to "Life of Pi").  I want to talk about security in the news that matters to myself and others, but also to talk about things that I'm learning.  I'm reading the C|EHv8 All-in-One right now, and I am skimming through the fantastic "Metasploit: The Penetration Tester's Guide", and once I finish with the C|EH, I'll begin working on learning more on Ruby and Python, which run Metasploit.

There's just so much I want to learn, and I often feel like there's too much, and that I'll never learn it all, as though I'm just trying to keep my head above water.  So, making this will help me chart my progress, and who knows, it may even be fun.

Take care, and if you want to talk, I'm on Twitter  @bryanbrake