BHDC 2010:  Joe Grand

Tired of Coding? Become an Application Security Specialist! (san jose south)

We have an immediate opening for a junior application security specialist (ASS) to join our growing consulting company. This permanent, full-time position is a great opportunity for someone with strong web application development skills that would like to move into the interesting and fun field of application security. This is a highly technical hands-on role that will utilize your web application development skills but involves little coding.

We will provide the right candidate with on-the-job training. The goal will be to quickly teach you how to perform detailed web application security assessments (black-box) and penetration tests by pairing you up with seasoned consultants. We have plenty of interesting projects to work on, including a wide variety of web applications (financial, e-commerce, gaming, etc.) and web services. Longer-term, we will train you to perform security code reviews.

This is an opportunity for a team player who would like to move into a new and exciting field, is ready to get started quickly, and is eager to learn some new skills and have fun while doing so.

Tired of Coding? Become an Application Security Specialist! (san jose south)

We have an immediate opening for a junior application security specialist (ASS) to join our growing consulting company. This permanent, full-time position is a great opportunity for someone with strong web application development skills that would like to move into the interesting and fun field of application security. This is a highly technical hands-on role that will utilize your web application development skills but involves little coding.

We will provide the right candidate with on-the-job training. The goal will be to quickly teach you how to perform detailed web application security assessments (black-box) and penetration tests by pairing you up with seasoned consultants. We have plenty of interesting projects to work on, including a wide variety of web applications (financial, e-commerce, gaming, etc.) and web services. Longer-term, we will train you to perform security code reviews.

This is an opportunity for a team player who would like to move into a new and exciting field, is ready to get started quickly, and is eager to learn some new skills and have fun while doing so.

Primary Job Duties
• Conducting web application security assessments and penetration tests. These are very systematic assessments which are done using our proprietary methodology, which we will train you on. The assessments involve manual testing and analysis as well as the use of automated web application vulnerability scanning/testing tools.
• Performing source code reviews using automated tools such as Fortify or AppScan Source Edition (Ounce) and/or manual analysis.
• Writing a formal security assessment report for each application, using our company’s standard reporting format.
• Participating in conference calls with clients to review your assessment results and consult with the clients on remediation options.
• Retesting security vulnerabilities that have been fixed and republishing your report to indicate the results of your retesting.
• Participating in conference calls with potential clients to scope out newly requested security projects and estimate the amount of time required to complete the project.

Work Location
Our company is headquartered in San Jose, California. The majority of work will either be done from either our corporate office or will involve driving to client locations throughout the Bay Area. Some of the work will involve travel.

Technical Skills
• Several years of experience developing web applications, preferably hard-core financial, e-commerce, or business applications that face the Internet. (required)
• Knowledge of the HTTP protocol and how it works.
• Experience performing web application security testing and using vulnerability testing tools. (preferred, but we will train the right person)
• Experience with web application firewalls (preferred, but we will train the right candidate)
• Experience with network-level penetration testing (nice to have, but not necessary)

Soft Skills
• Solid written and verbal communication skills.
• Willingness to do hands-on, highly technical work.
• Strong customer focus. The goal should be to make customers happy enough that they ask for you to be sent back to do more work for them.
• Desire to learn new things and become a participant in the local information security community.
• Honesty and integrity.

Other Requirements
• Must undergo criminal background check and drug testing.
• Flexibility to work odd hours at times. For the most part this is a Monday-Friday 8:00 to 5:00 job, but sometimes customers require us to do certain work during weekends or off-hours.

Job Benefits
• Competitive salary including performance incentives
• Reasonable work hours compared with most information consulting firms. We expect employees to work hard and produce results, but we also understand that our employees have a life outside of work and are not a 60 hour per week body shop.
• Company sponsored medical and dental insurance
• Company sponsored training programs and career growth opportunities
• Company sponsored industry certifications necessary for your position (such as CISSP, CEH, etc.).
• You’ll be part of a closely-knit team of dedicated employees.
• Your choice of beer (at the end of the workday)

If you think you’re the right person for this challenging and fun career opportunity, please reply with your resume.

My kids are little geeks, similar to many of your kids in all likelihood.  They wake up in the morning and hop online or start playing on the DSi, or just pick up a book and read.  Their favorite magazines are Make and Science Illustrated.  And some fool introduced them to Japanese (is there any other type?) anime a couple of years ago.  So a convention aimed at teaching them how the Internet works, how to stay safe online and building robots really appeals to them.  Add to it that the convention is happening at the Microsoft NERD center and MIT is just down the street and you’ve got something that budding geeks will find unresistable.

If you’re on the East Coast anywhere near Boston, have kids between the ages of 5 and 17, think about taking them to HacKid in October.  Do keep in mind that every young person must be accompanied by an old person (read: adult guardian), but that each of the classes will likely have almost as much to teach the adult as they do the kids.  Everything is being done on a volunteer basis and the event is organized as a non-profit, so the money is all going to a good cause.  But hurry if you’re going to sign up, the cost goes up from $50 each to $75 next week. 

Show Notes:

• Witty banter, conference updates
• HacKid conference, October 8 and 9, Boston, MA
• Changes to Foursquare’s authentication system
• OpenSSH 5.6 arrives
• Exploiting DLL Hijacking Flaws
• Intel buys McAfee
• Tonight’s Music: This One’s A Cheap Shot by Every Avenue

]]>The gang reunites this week after skipping an episode and, despite wondering if Rich’s house was going to get blown away to the merry old land of Oz, squeezed out a show — and even included our very first bumper (from our friends over at Eurotrash Security Podcast). Yes, we did cover the proverbial “elephant [...]http://www.mckeay.net/2010/08/24/network-security-podcast-episode-209/feed/0noMartin McKeayThe views of one man on security, privacy and anything else that catches his attentionPodcasthttp://www.mckeay.net/2010/08/24/network-security-podcast-episode-209/http://feedproxy.google.com/~r/MartinMckeaysNetworkSecurityBlog/~3/MpdZB2skyz0/Podcastnetsecpodcast@mckeay.net (Martin McKeay)Sun, 22 Aug 2010 12:33:08 PDThttp://www.mckeay.net/2010/08/22/black-hat-2010-branden-williams-rsa/Branden Williams is one of the thought leaders in the PCI field, or at least someone like me who blogs about it a lot and hopes others find value in our thoughts.  I had a few minutes to catch up with him at Black Hat, where we discussed what he’d seen at Black Hat as well as the upcoming changes to the PCI DSS.  It appears that not much has changed since our talk and that the conclusions that we drew still remain consistent with what the PCI Council has released since then.  Pardon the background noise, we accidentally chose what we thought was a quiet corner but turned out to be one of the major staff entrances and exits.

Black Hat 2010:  Branden Williams, Director of Security Consulting,RSA

While I do have a lot of experience in PCI, I will never claim to have the all the answers to securing a cardholder environment.  I won’t even claim that I understand all the implications that writing a policy and technology framework like the PCI-DSS.  But I do have some ideas around how I’d do things differently if I was writing the requirements.  Boy do I have some ideas.  And I know that I have a lot of friends and peers in the industry who are more than willing to give those ideas a thorough looking over and thrashing to separate the wheat from the chaff and help me winnow out what’s useless from what can really help the industry in the long term.  So over the next couple of months, I’m going to lay out a series on how I’d write the PCI-DSS.  I expect that many of the ideas I throw out will be torn apart, but I want to encourage people to start thinking about how we can change the standards going forward.

One of the reasons I’m starting this right now is that the PCI Council has just released Summary of Changes for PCI 2.0 and changed from a two year to a three year lifecycle.  While the changes aren’t set in stone as of yet and all we have so far is an outline of what these changes are, what we have seen is nothing more than minor clarifications and minimalistic guidance for virtualization.  Since the new changes aren’t fully revealed yet, it’s hard to be too tough on the PCI Council; yet minor changes coupled with lengthening the time between revisions seems to be a plan to calcify the PCI-DSS and protect anyone from having to make major changes to their environments.  I feel there’s been enough time and feedback that this approach is not in the best interest of security nor is it really in the best interest of the public.  Bluntly put, the change to a three year life cycle should have been accompanied by a major revision of the requirements, not the minor tweaks we’re getting.

I won’t call what I’m thinking of PCI; the PCI-DSS is what it is and I can’t change that directly.  What I’ll be writing is just a series of thought constructs based on what I think are the real steps we should be taking to secure the credit card process.  I want to think outside the box that we’re currently in, looking at what we do now and trying to understand how we can do it better without tearing apart the merchants and service providers with additional costs and burdens.  I’m realistic enough to know that anything that requires large amounts of time and money are going to be met with screams of denial and pain.  But I also know we can refocus many of the efforts we’re making now and use the same tools we already have in place more effectively.

I want to start with a few principles that I think everything else should derive from.  And I know even these principles need to be challenged and refined.  The first of these is simple:  Everything flows from policy.   This is currently the last requirement in the PCI-DSS and I have always thought that it was the biggest mistake that was made when the original CISP requirements were written up.  As it stands now, policy is stuck onto the end of the requirements almost as an afterthought, even though in many companies it’s what gives the teams trying to secure the environment the ability to make clear cut decisions about what is and isn’t acceptable in the cardholder environment.  It’s also very helpful in getting the budget to purchase the tools you need.  Of course, I’ve already had one person tell me that starting with policy is doomed to failure, but this is my framework, so too bad.

The second principle is Keep it simple.  Come on, 200+ requirements??  How many of these are redundant, needless or just a vestige of something that is no longer reasonable to require.  We’re still required to check for a stateful firewall, even though every firewall built in the last 5 (10?) years is stateful.  I’m sure you can think of dozens of other requirements that are similarly outdated and needless.  Why have requirements that are simply placeholders that serve no real purpose?  Once a requirement becomes outdated, it needs to be retired to make room for something more important.

My final principle is Concentrate on results, not technologies.  There are very few things I like to see more in an assessment than a client who’s met with the PCI-DSS in a way that goes well beyond the simple requirement and actually secures their environment.  Andy Ellis, aka @CSOAndy is one of my heroes in the industry because of everything that he and his team have done to secure Akamai.  I need to talk to him to see how much he’s willing to disclose about what Akamai does differently, but let’s just say that his compliance assessments are truly unique and not something you ever want to send a junior assessor to deal with.  My goal is to develop a framework that concentrates on the results we want to see, not the tools you have to have in place to make it happen.

I think I’m taking on an impossible task here.  But I my goal isn’t to tell anyone what they’re doing wrong; it’s to come up with alternative ways to meet the same goal, which is securing the credit card process and promote security for enterprises overall.  I’m going to stumble a lot, I’m going to make mistakes and people are going to tear my ideas apart.  But if I can get you thinking about how we can do things differently, I’ll consider this experiment a success.  I want people to consider what we’re doing now and how we can do it better.  Some of my ideas will be thought of as impossible in the ‘real world’; some ideas will be taken almost directly from the PCI-DSS. And some will be taken directly from friends and peers.  My biggest fear is not being criticized for the effort; my biggest fear is that it’ll be ignored.

I got to talk to Bob Russo from the PCI Council in July, and he’d hinted at the level of change.  And maybe I’m just not realistic in asking for major changes.  Despite the fact that PCI has been around for a while now, there are still a lot of merchants and service providers who have issues complying.  It may be that the realistic thing for the Council to do is continue to build support and compliance with what they have now, rather than pushing to increase security by making major changes.  Sometimes it is better to accept minor changes you know you can enforce than to try for something grander that you’ll never attain.

I’m hoping to get another chance to talk to Mr. Russo.  I’ve asked nicely, really I have.  I’d like to understand why this is the sum total of changes they’re making before switching to a three year lifecycle.  I’m not sure I’ll like the answers, but I still want to hear them directly from the man who’s in charge of the group setting and managing the PCI Standards.  Obviously, my approval is not necessary, but as one of the people who helps enforce the PCI Data Security Standards, I want to understand the reasoning.

Network Security Podcast, Episode 208, August 10, 2010
Time:  45:27

Show Notes:

• Listener Q&A (half the show)
• Disclosure spat on Twitter (no link)
• Don’t plant child porn on your boss’ computer
• NatGeo goes to DefCon (great article!)
• Tonight’s Music:  What about the Love? by Art Linton