JACADIS Thought

Security training approach for developers

A question was recently posted to the Federal Secure Software Advisory from Fortify:

“In my company, there are conflicting opinions on how much time we should spend training developers in hacking techniques versus writing solid code. What do you think? Should we spend 50 percent of the time on each? Or 20/80? I'd be interested in hearing about what others cover in developer training.”

I think it’s outstanding that companies are thinking like this.  Let me offer an expanded version of my answer:

It is my practice to recommend an 80/20 to 70/30 range. But, how much time you allocate should consider the types of applications that are developed by your team. While most exploits have their roots in the same mistakes such as unchecked buffers and unsanitized inputs, etc., the mechanics of how they are exploited over the network against Linux desktop may not be time well spent for a .NET web developer focused on Web 2.0. In fact, too much information, especially for developers with limited security exposure, may dilute your training efforts altogether.  This leads to a critical learning concept that I like to capture in three sentences:

Tell me and I may not listen

Show me and I may not watch

Involve me and I will learn

Catchy, but what does that really mean?  It means, take advantage of how the human brain works by maximizing all the senses; not just hearing and sight, but tactile as well.  And by making it personal, you make what is learned readily applicable. This is too important to miss since companies are doing more with less; developers are overworked; security is complicated – make the most of the time you’re given to get the concepts applied. 

I prefer a blended training approach that combines hacking techniques with secure coding in a single training. Emphasis is placed on challenging developers to think about the code they’ve written (and will write) and how it affects security at the client, web, and data tiers. Let’s assume you have 40 hours to get your developers up to speed on secure coding. Allocate 8-12 hours to exploring pertinent web application weaknesses, how they are found, and how they are exploited. The developer should be exposed to manual exploitation. Avoid introducing complicated tools, scripts, and exploits, as the emphasis is to make them developers that code securely, not developers that can penetrate applications.  If you introduce any tools at all, ensure they are ones they will continue to use after training is complete.

The techniques learned in the first 12 hours are used to stimulate conversation regarding potential weaknesses in your environment. With proper planning a “typical” internal app can be decomposed and analyzed during the training. Secure data sanitizing approaches can be taught, after which the in-house application can be evaluated for compliance with secure standards. This not only teaches the proper coding approach, but also exposes developers to the process of identifying weaknesses.  BONUS: If developers feel empowered to find software weakness they won’t rely on (or assume) others will find them.

I’ve found that in-depth hacker training introduces too many concepts and tactics that are not useful in the day to day activities of developers. Developers learn something new, but find themselves wondering how to use that knowledge in a day-to-day basis.  It’s not enough to know the techniques; your teams must be able to retain and quickly apply what they’ve learned. 

Si

DDOS: The Achilles heel

According to the Washington Post, Amit Yoran describes the widespread DDOS attack against US Federal agencies as "loud and clumsy," suggesting it was carried out by an unsophisticated organization.  This statement led to a simple question during a phone call with a network security analyst at a state agency.  “If this was executed by amateurs, then why couldn’t the experts prevent it?”  This is a great question that deserves a analogy:

Give 10,000 uneducated men a loaded weapon.  No military experience is required.  Point them at a target and have them squeeze the trigger.  The attack will be suppressed, but not before there are casualties or loss of life.  It doesn’t have to be pretty, you just need enough force.

It’s the same with DDOS.  Substitute armed men for bots/zombies and bullets for billions of packets aimed at Federal agencies.  Whether you flood your target with waves of armed soldiers or billions of UDP packets, it’s the same principle: defenses can only withstand a certain level of pressure.  We’ve known for over a decade that the Internet’s Achilles Heel is DOS/DDOS.  But this vulnerability can only be exploited when sufficient force is applied. 

If the goal of this month’s cyber attack was to temporarily disrupt the web presence of US Federal agencies, amateurs or not, their mission was accomplished.  Returning to original question regarding experts preventing amateur attacks, let me offer a better question: What will happen when the “experts” launch an attack?  Temporary disruption is just the tip of the ice berg. 

Si

The Layer 8 Effect

It's a startling fact: the JACADIS security consulting team has penetrated the networks of government, medical, private, and public sector organizations in a matter of minutes.  Thankfully, we’re the good guys; our clients want us to show them how they can be “hacked.” Our approach is simple and emulates the same tactics used by sophisticated data thieves and cyber criminals: target "Layer 8" -- the employee.  Our success rate? 100%  We've tricked managers, executives, supervisors, directors, secretaries, and professors into giving us access, usually with a simple click, and sometimes with no interaction at all.  The weakness?  People.

Technology is not a substitute for good computer skills and common sense.  We believe people have an unrealized role to play in the protection of personal information, financial data, and corporate secrets.   Technology will fail and people, the last line of defense, must must stand in the gap.  As this concept is accepted, the Layer 8 Effect will begin:

• a decrease in accidental disclosures due to carelessness
• employees that genuinely understand the need for restrictions versus scoffing at them
• focused, task oriented workers that are not as overwhelmed by their in-box and vulnerable to Phishing attacks 
• an increase in users reporting suspicious activity
• more users, both corporate and home, that use the Internet with greater skill and awareness, not easily duped or carelessly clicking on whatever comes their way

Will the Layer 8 Effect solve the rampant problem with Identity Theft and  hacker attacks?  No.  It will curb, however, the number of breaches that happen because of carelessness with social networking (Facebook, MySpace, Twitter, etc.), poor email habits, and a lackadaisical attitude regarding confidential information in general. 

Why should you care?  Your identity may be used to commit a crime, fund criminal activity, or support terrorism.  Your personal computer or company laptop could be used to attack businesses, governments or nation states.  No one is immune. 

We hope you're ready to do your part.  This initiative needs you, your family, and your company to participate.  Follow us here and on Twitter.  If you're a business professional, join our LinkedIn group to help remove yourself and your organization from the ranks of the easily fooled, to one that stands in the gap at Layer 8.

 

Cyber attacks: The value of Detection and Response

The recent cyber attacks against US federal agencies underscores a concept that each JACADIS client is taught early on.  “Prevention will fail.”  It is at this point that you must be able to detect and respond.  Failing to do so may severely increase the impact of the event.

The objective of this post is not to call out the Fed’s inability to thwart a large scale distributed denial of services attack (DDOS).  Rather, my goal is to emphasize the importance of knowing when your systems and networks are under attack and how to respond.  During an attack is not the time to discover you have no idea who is attacking your organization.  And similarly, wondering who to contact for help, whether it’s for security expertise or your ISP for blocking the attacker upstream, should not occur while your being hammered by a DDOS attack.  Answers to these questions should be known, documented as processes, and tested to ensure they can be followed when a real incident happens.   

Risk analysis and threat modeling is a critical success factor in planning for security incidents.  This does not need to be a difficult or expensive process.  Self-directed models, such as OCTAVE Allegro enable organizations to achieve sufficient risk and threat assessment results with minimal time or cost investment.  There will be more attacks; perhaps your systems will be part of the bot network that attacks our nation’s infrastructure?  Start evaluating now how this might happen, what you can do to prevent it, how you will detect it if prevention fails, and what resources you’ll need to respond.

Si