Cатсн²² (in)sесuяitу / ChrisJohnRiley

Because we're damned if we do, and we're damned if we don't!

Tag Archives: bsides

#BSidesVienna: Ticket Challenge

After the amazing success of the Phase 1 and Phase 2 tickets, we’ve decided that the 3rd and final phase of ticket assignment for BSidesVienna needed to be something a bit special. After all, it’s easy to click a button and get a ticket… It’s also free, and we all know people love free things. So, for this phase, we’re going to make you work, just a little bit!

The challenge is a simple one…. Now head over to http://untrustedsite.net and get to it!

Entries are to be in the form of email to the correct challenge address (finding the right email address is the challenge). You don’t need to attack, brute-force, or otherwise hammer the system to get the answer. People found doing so will be banned from the contest and laughed at accordingly. Oh, and yes, I do check the logs 😉 Entries will be taken on a first come first serve basis and must be in by midnight (Austrian time) on May 6th. That’s Friday, for those without calendars! So what are you waiting for… you wanted more tickets, so get to it!

Now, this is either going to be very very easy… or very very hard? It’s always hard to judge when putting together a challenge. So, I’ll be throwing out some hints through the @BSidesVienna twitter feed over the next few days. For those that need it 😉

BSidesLondon

Well BSidesLondon has come and gone, and what an event. Considering this was the first BSides in the UK it seemed like it had been running for years. Everything was smooth, well planned, and executed. If this was the first event, I have high hopes for the second 😉

I really enjoyed the Track 3 idea… A free room with projector and a signup sheet. Very unconference style! I signed up to do a quick 30-minute SAP talk (scrubbing SAP clean with SOAP), which went down well I hope. I’m not sure about uploading the slides right now, as there are some things that I’m still working through with SAP. Nothing serious, but enough to make you think. Still, maybe I’ll put the talk forward for BSidesLasVegas 😉

Note: If you saw my SAP talk, I’d love feedback on what I can improve… Be harsh, it’s the only way I can improve!

I was lucky enough to be able to “present” as party of the Security YMCA troupe (along with @f1nux, @seccubus, and @suggmeister). I say present, but really it was just a bit of fun. Singing, dancing and funny costumes are great for funny YouTube videos (which I’m assured are already uploaded), but I doubt any real content got across… Still, you can’t blame people for not listening to a man dressed as a gay biker when he says the security industry doesn’t communicate well enough 😛

I’d like to thank all the people who put on BSidesLondon… There are too many to mention, but they know who they are! Looking forward to the next edition already… And BSidesVienna as well obviously!

BSidesLondon: How not to get hired for a security job

 How not to get hired for a security job

Stephen Bonner

Why people fail in the hiring process… by doing stupid things!

Some things that I tell you NOT to do, might be what your future employer wants… it’s not easy to define.

The process of hiring is about finding somebody that will fit in and add value to the team. It’s not all about the skill set.

The most important is to hire people for attitude. People don’t often get fired for their lack of skills, most get fired as they don’t fit in!

When you start the process of getting a job is to get involved with an agent… these agents don’t have your best interest in mind! Consider that. They aren’t aligned to your values. They’re in it for the $$$

Sending emails and CVs out of the blue to most companies is also a bad idea. There are some clearly defined processes, and trying to avoid them usually ends badly. Going through an agent is sometimes the best way.

The first thing an agent will do to your CV, is rip it apart to remove contact info… and therefore screw it up. It’s also worth asking for a copy, as some less reputable agents ADD skills!

Please check your CV for spelling and punctuation… oh and if you list reading on your CV as a hobby (which I’d expect from a 5 year old), please actually read something… and know what you read last.

Listing certificates on your CV doesn’t say your smart, it just says you worked at a company that had a training budget! Many HR departments put the same weight on a CISSP as MSc!

Photos in CVs… are just creepy!

It is extremely likely that an employer will Google you… look through your Twitter, Facebook, LinkedIn, etc… Even if it’s not legal/right. If you have a profile, make it a good one. If not, deny it’s you 😀

The Telephone Interview

Cut out the background noise… oh, and chance are the other end is on mute, reading their emails!

If you talk for 20 minutes and the other end says nothing, they might have gone! Get feedback. Challenge and answer.

The interview

Being nervous and mumbling… not good. The employer doesn’t care!

Don’t be late, and if you are, have a great excuse (i.e. brought a man back to life on the tube).

Nobody wants to hire somebody who you would want to spend a night stranded in an airport with. Maybe, look like a blanket?

Key questions

What is your password?… 30% of people answer, and they don’t get the job.

If you can’t stand the social engineering pressure of being asked, maybe this isn’t for you.

Nobody replies, “I don’t just have 1 password!”

Best answer was “I can’t tell you”… “because I don’t know what it is”. “Because it’s a pattern on the keyboard”. He then draw out the pattern on a fake keyboard. It was a crap password as well!

Have you ever hacked illegally?

The answer to this is always NO. If you can’t understand the context and lie accordingly, you’re probably not going to get the job.

The NO-WIN situation

Just like Star Trek… put them in a situation they can never get right. See how people who always succeed deal with failure. Covering it up and denying it happened, isn’t a good plan. Deal with the failure.

Team work

How you deal with communications and then follow simple instructions. It’s all about the communication and figuring out issues before they happen

Have you got any questions?

Do ask… and no, holidays isn’t a valid question.

Check you’re applying for the right job. Oh, and the right interview.

Don’t lie about your experience and job. It can be checked.

Don’t slag off your employer. The prospective employer knows you’re going to talk crap about them in the future too!

What happens when you get the answer (NO)

Don’t argue, but get feedback

Arguing doesn’t help. They’re not going to change their mind after all.

Links:

BSidesLondon: Jedi mind tricks for building application security programs

 Jedi mind tricks for building application security programs

David Rook and Chris Wysopal

Most developers actually want to write secure code

You need to take ownership of the app sec problem and not just hand them a list of bugs. Just telling them where things are bad doesn’t help them understand the code that needs to be written to make things better. If security requirements aren’t in the spec, then how can you expect them to design and code secure code? Things need to be in place to let them write secure code.

Developers generally like producing quality code and want security knowledge. Use this! If you define quality as secure, then it’s a lot easier to get the code you want and need.

Following something like the Microsoft SDLC is great, but only if it meets your companies needs and requirements!

So what do we do to help developers?

They are the ones that will make the security program a success after all!

Help them understand how to write secure code. Obvious really, but often overlooked.

Own the security problem with them. Don’t be the auditor that just says when things are wrong. Don’t dictate! Speak, listen, learn and improve things. The “I’m the security person, I’m right” attitude isn’t helpful here!

Help developers catch faults before it gets to the security testing phase. Clear security test cases for developers empowers them to make things better themselves. Buying licenses for Burp Suite for your development team isn’t a waste! Empower them to make things better!

We speak an Alien Language

We talk about injections, jacking, pwning… if they don’t understand the issues, and we don’t speak the right language, then how can you get the support and budget you need. If your findings aren’t readable, they don’t help anybody.

How do you get management and C-level to sign off on secure code! How do you get a project manager to understand they need to hold things back a week to make it secure!

We present findings in weird formats using weird measurements.

Using things like CVSS is all well and good, but doesn’t translate to business risk well.

CVSS scores can make things look a lot less of an issue than they really are. Depends on the temporal and environmental scores. Does it make sense to a tester? a manager? a developer?

We feel security should just happen without having to justify it.

We need to speak the business language

Why should they care about injection X! Talk the business langauge and convey things in ways they can equate things to real business impact.

We need to format things in a format that makes sense.

Use examples that show brand issues after hacks… RSA springs to mind. If you Google RSA security, the first page is nothing but news reports on the hack. THIS is business impact.

How does your business score risk?

Scoring security rankings on a different way means they lose business impact, and can be ignored easier

We’re not saying dump CVSS, but also convey the risk in the way business can transfer it to business risk easily. Whatever they use, no matter how it looks.

Application security is NO exception when it comes to resourcing.

Apply the KISS principle

Keep everything as simple as possible

Understand what developers want and need to write secure code. It’s not just a yearly refresher on what the new OWASP top ten is!

Work with the business to understand what they care about.

—————

Why do we need executive buy-in?

We need tools, training, services… and it’s going to affect the business!

If a secure developement program needs to be implemented, it can’t be an opt-in. Without business buy-in, things are hard to enforce. Some departments won’t be interested.

Business buy-in is required.

C-level thinks in $$$

How can security reduce risk, lower costs, and help grow the top line?

How can you transfer security issues into numbers that make sense to the C-Level?

  • Legal Risk –> Legals costs, settlement, fines
  • Compliance Risk –> fines, lost business
  • Brand Risk –> Lost business
  • Security Risk –> ???

If security risk is the only thing not quantified, how can you expect buy-in. How can we do what these other professions already do?

Translate technical rick into monetary risk

What is the monetary risk from vulnerabilities in your application portfolio

Use breach costs to estimate the costs. There’s not enough data out their yet about breach costs. Unless your company has experienced a breach, then you have to use external sources.

Ponemon Institute created a per record view of breaches (April 2010) that shows some information… if your company is worried about exposure of PII

Financial breach costs $248 per record… how does this relate to your company!

Using threat space data is also useful for showing where the threats come from (at least for those reported).

40% of breaches are due to hacking (from 2009 DBIR)… breakdowns of root cause allow us to really measure real word use of vulnerabilities. However, the data is mostly PCI based, and might not be useful for your industry vertical.

There’s not really enough data out their if you don’t fit the model (mostly financial PII exposure).

Using all this data you can come up with the likelyhood of a specific vulnerability being used to exploit your company. It’s not the final data needed, but it gives a starting point for discussion and allows you to gauge if your company is better or worse than the norm within the sector.

Understanding what the real world $$$ cost is of these vulnerabilities on a company-wide level. Developers care about the single app, but C-Level care about everything within an organization. This includes code not from in-house sources. Your application developer program needs to incorporate this.

Your program needs to actually be achievable.

Tips to make the program successful

  • The right people have to understand what is going to happen before you start
  • Do a real world penetration test or assessment of a project. Demonstrate risk!
  • Integrate into processes (SDLC, Procurement/legal), M&A)
  • Make things relevant to the developers. Don’t show them example code and fixes in JAVA if they code in PHP
Links: