JACADIS Thought

SMBs and DMZs...

I’ve seen my fair share of networks that are solid on the outside, but soft on the inside.  But I’ve also seen a handful of networks that are solid throughout.   It starts with a well managed firewall at the edge, a strict inbound (Internet) network policy, at least one DMZ, and sometimes an additional firewall inside the private network.

In small to medium businesses (SMBs) there’s often push back regarding the deployment of a DMZ.  Admittedly, if the network, and applications that sit on top of it, were not designed with “least privilege” in mind from the start, a moderate degree of effort, plus some additional hardware will be required.  You might even need some third-party assistance.  This translates to both effort and cost, which puts people off pretty fast.  So what’s the real driver behind a DMZ, or internal firewall, for that matter?

Reduce the attack surface, isolate threats, & protect high value assets

You'd never put a production Apache or IIS web server outside the firewall (I hope!)  There’s too many services exposed and therefore too much risk, or potential for damage.  So you put those assets behind the firewall and only allow public access using HTTP.  By ensuring the web server is patched and the application is free of OWASP type bugs, you further reduce the risk associated with a break-in.  So far so good. 

Now here's the risky part -- your Internet website is directly connected to your private LAN.  In fact, it shares the same subnet as your internal servers and workstations.  When Internet users (and hackers) view your website, those requests travel through your firewall where they are processed by the web server on your private network…  the same network where your employees access personal information… the same network where HIPAA or PCI data may be stored in a database.

Depending on your business risk, allowing public Internet traffic to connect to hosts on your private network is like letting bank customers do business inside the vault. Every once and while, a thief is going to get in; by the time it is noticed, it could be too late.  In network security terms, I am referring to a cyber-criminal or malicious process finding a weakness in the web server that sits on your private LAN.  By the time you realize you’ve been hacked, it’s too late.  The intruder is already on your network with un-firewalled access to your internal servers, workstations, and devices.  It's trivial at this point to install keystroke loggers, sniffers, or a backdoor that lets the intruder secretly slip back into your network if he's discovered.

By connecting the web server to the DMZ switch, versus the private LAN, you can restrict potential intruders to the DMZ only.  In the case of web server that communicates with a backend file server or database, you'll need to poke some holes to allow that traffic from the DMZ to the private LAN.  Does this weaken the model? Yes, but not significantly.  After all, the point of the firewall isn’t to block everything but to strictly allow what is required to support business applications and services.  This means permitting traffic from specific systems on the DMZ to a handful of internal hosts and specific ports.  

Rarely do the cost savings, convenience, and ease of not having DMZ outweigh the potential damage from a break-in. The key take away from this post is to reduce your attack surface, isolate threats, and protect high value assets.  A rapid and cost effective method to achieve this is with the proper deployment and management of network access restrictions, typically using a firewall or VLAN ACL.

As always, your feedback is welcomed.

Si 

Props to Acunetix

Just a quick post to give props to our friends at Acunetix.  For the third year in a row, they've won the Reader's Choice award from Windowssecurity.com. Congratulations!

Interestingly enough, I spent time this week in both Detroit and Cleveland helping a software development firm and a publicly traded company learn how to find and fix vulnerabilities like XSS and SQL injection using Acunetix WVS.  At both locations, it was encouraging to have not just security managers present, but also JAVA and .NET web developers, analysts, Windows and Linux system engineers, and SQL, Mysql, and Oracle DBAs.  To me this indicates a growing understanding that keeping web applications secure is a cross-team effort.  And it must begin before the application is released to production.

To echo the sentiment of WindowsSecurity.com readers, let me close this post by sharing a quote from a DBA participating in the sesson:

"Acunetix just paid for itself!" 

So what prompted this exclamation?  Acunetix WVS found a series of exploitable SQL injecton holes missed by their PCI/DSS auditor's tool.  In fact, there was no trace at all of any SQLi holes in the auditor's scan report.  And both tools scanned the same code...      

Props to Acunetix!

Si... 

 

Software liability... will it make a difference?

Insecure code is written every day.  The impact may range from a Windows “blue screen of death”, to cellular service outages, identify theft, critical infrastructure failure, and so on.   How bad code affects you may vary based on where you work and what you do.  For home users, the damage may be minimal.  For business, the costs can be tremendous.

A posting on Bank InfoSecurity this week asked the question, “Should software developers be held liable?”  While my response to this question is yes, it assumes software negligence can be measured, or it can be shown that a standard of due care was not applied.  Fail this test and you’re in hot water.  So how should companies address the possible threat of being held accountable for bad software?  Education is a great start.

Unfortunately, education these days focuses on making sure applications don’t have any of the Top-10, Top-25, or Top-N security holes.  With a prevalence of lists, such as CWE/SANS Top 25 Programming Errors , developers can become focused on what not to do, versus what to do.  Sure, we need to know what practices to avoid, since there’s definitely merit in quantifying common mistakes and encouraging others not to repeat them.  But is software security really improved by creating new lists year after year?  I am skeptical.

“DON’T DO” lists are no different than black-lists, also known as a negative security model.  As long as we can describe what we don’t want, we can include it in the naughty list, and then block it.  For those of you that have worked with black-listing, you know it’s an endless chore of updates and tuning.  As new threats or bad behaviors are found, we have to update the black-list.  It doesn’t end.  This explains why the Top-N lists need to be updated annually.

“DO” lists, or the positive security model, describes only what is good and allows nothing else.  If an activity falls outside the “good list”, it’s simply not permitted.  With this contrast between negative and positive filtering in mind, I suggest that a stronger emphasis on defensive coding practices will lead to more secure software.   

The threat of legal action shouldn’t force software developers to do what is right.    A zeal for quality and excellence should do that.  After all, HIPAA was enacted in 1996 and we still have privacy leaks.  The PCI/DSS standards council has existed since 2004…  You can read into that anyway you like. 

Cheers!   Simon

“Crappy network!”

My 14 year old son texts me sometimes while I am working.  He knows what we do at JACADIS and thinks it’s the coolest job on the planet (I agree!)  A recent exchange of messages flowed something like this:

B: “Sup?”

Si: “Testing a network”

B: “How long to break-in?"

Si: “Seconds”

B: “Crappy network!”

His last text made me pause and think.  I guess I could agree. After all, it did take a matter of seconds to get root access on a server containing confidential data.  But is the network crappy?  Let’s see:

• The network is always available
• The applications which ride on top of the network are always up
• Critical business units can access network services when needed and without interruption

Sounds like the network is functioning well.  Perhaps what he meant to say was “crappy security!”  Let’s test that.  The security program includes…

• A Cisco ASA with a very strict inbound and outbound access-list (firewall policy)
• A separate in-line, deep packet inspection IPS sensor
• Hosted content filtering and URL inspection (forced proxy)
• Managed Antivirus/Anti-spam services
• Desktop and server Antivirus
• A dedicated security staff with access to IT specialists in other units as needed
• Established and current security policy, sign-off by employees, and annual review
• Periodic security reminders as threat conditions change on the Internet, i.e. new worm, phishing scheme, etc.

Not bad.  In fact, this is actually better than some of the HIPPA, SOX, and PCI regulated organizations that we’ve had the privilege to work with.  So, this client’s security isn’t “crappy” either. 

I was born in England.  I coach soccer and my son plays as well.  It’s in the blood, so to speak, so I thought a soccer analogy might resonant with him…

Si: “Crappy?  Yes and no… When u lose a soccer game it’s not because ur team is crappy.  Ur outplayed, out skilled.  It’s team execution – all parts must work together.”

B: “And that’s why they call you in!”

Si: “Yep!”

Was I suggesting to my son that we out skilled our client? Or that our team was better than their team? In a sense, yes, but more importantly this metaphor was hatched:

Cyber criminals and hostile nation states execute a highly skilled game with precision and power.  The defensive tactics that previously kept the “hackers” from scoring is insufficient against these premier league tactics.  They have stepped-up their game… brought it to a new level.   

If JACADIS penetrates your network in seconds, it doesn’t always mean “your security stinks!”  It means our team tactics and strategy surpass what you have installed or even considered.  What worked 2 years ago, is not good enough today.  10 foot wall … 11 foot ladder. 

Key points?  Adapt.  The adversary has.  If you don’t know where to start, begin with a framework that makes security a living, integral part of your organization…ARMED.

-- Si

Adobe exploit in the wild...

This isn't earth shattering news... but it does speak to this:  Expect the bad guys to use familiar tools (things you use each day) to gain access to personal information.  Why Adobe?  Why not!  It's free and many people use it.  In fact, the JACADIS security team uses "infected" Adobe PDF files to evaluate how well employees follow basic security awareness rules.   We also use it to test assumptions regarding how well a company's prevention, detection, and response safeguards stand-up to cybercrime-like attacks. 

A couple days of "harmless" and tactically sent Adobe attachments and links confirms several things every company needs to know:

1. Do our inbound content filters prevent malware from entering the corporate network?
2. What about the desktop? Does the host AV/IPS detect when the callback agent embedded in the Adobe file phones home?
3. Do outbound web content filters categorize the "call back" location as malicious?  Is it categorized at all?
4. And the SIM... Oh, the SIM .  Does it intelligently correlate all of this activity, relatively obscure in its parts, but significant as a whole?

Perhaps you'd be surprised if I told you most people can't even answer yes to at least one of these.  What's more, we don't go through great lengths to hide our call back servers or encode our traffic.  We keep it simple.  And simple works.  

Simple worked at a public insurance company, even with several layers of security deployed like Cisco IPS, ASA, CS-MARS, McAfee antivirus, and hosted AV/SPAM filtering.  We phished our way onto the network in two minutes.  Nothing logged our activities.  Thank goodness we're the good guys.

If you think "deployed" means "secure"... think again.  If you have doubts, drop me a note.  I'd love to hear from you.

-- Simon

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

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    

Data for hostage

Many of you have heard me mention the “Cyber Mafia.” Some of you chuckle, grin, and raise your eyebrows at first. The rest of you know organized crime is a prevalent and dangerous threat. To drive this point home, I want to share a security incident I read about in the Washington Post this week:

“A posting on Wikileaks.org claims that cyber attackers stole data of about eight million patients from the Virginia Department of Health Professionals' Virginia Prescription Monitoring Program website; they are demanding US $10 million in ransom for their return. The intruders claim to have encrypted the database and protected it with a password. That particular site is presently unavailable as are several others related to the Virginia Department of Health Professionals. The ransom note says that if the money is not paid within seven days, the data will be offered for sale. Federal and state authorities are investigating.”

Cyber extortion isn’t a new threat. Crime syndicates have used massive botnets to launch denial of service attacks against gambling and gaming sites before. Only when the ransom is paid does the DOS attack stop. “Protection” is then offered, for a fee of course, to prevent other criminals from launching additional attacks. But what about taking sensitive information, claiming exclusive access, and threatening to sell that data? Sure it’s also been done before, but this attack is overt and gutsy.

If it’s really that easy to steal 8 million identities from a government agency, then this is a signal to other criminals that there’s money to be made and the fields are ripe for harvest.

I predict there’s more of this to come. But please don’t be fooled -- you don’t have to be a state or federal organization to be targeted. Public, private, or non-profit, if you store, forward, or process confidential and personal information (PHI, SSNs, CCNs, etc.) for clients or employees, then you need to carefully consider the following questions:

1. What’s valuable to your organization, where is it stored, and how is it forwarded and processed within your company?

2. Who has access to it, how do they access it, and from where is it accessed?

3. What does the law say about your security practices from #1 and #2. Do you have a plan to close the gaps?

4. Do you frequently verify that security safeguards are functioning as designed?

Meet with your IT management and Executive team to find the answers. This is more than firewalls, antivirus, and a good security policy. If these answers aren’t “at your fingertips” or available within 1 business day, then we need to connect and chat.

Security focused,

Simon

A "D-" is good enough

This post is prompted by an exchange with a client that develops and hosts web applications for customers.  A recent automated vulnerability scan performed by the developers, on behalf of their client, revealed that a possible blind SQL injection point had been located in an aspx file.  As clear as day, passing bad data caused an unhandled exception, which was visible in the browser due to custom error messages being enabled.   The error message included a stack trace, the name of the database table used to authenticate users, the directory where the application was located, and the specific lines of code where the exception occurred. 

Attempts by the client to exploit the injection point were not successful, so a heated discussion arose between the developers and the client.  It did not center around how to fix the issue, but whether or not the named vulnerability actually existed.  In this case, the text of the alert was "Possible Blind SQL injection", pointing to the aspx file and the variable used in the injection. 

Now the discussion over the scan result is understandable: is it really SQLi or not?  Can data be extracted from the table "tblUser" or not?  I get this.  But what about the bounty of data contained in the stack trace, confirming that bad data caused an exception?  SQLi, RFI, XSS, XSRF -- who cares what it is called?!?  The code, as written, faults when bad data is passed! 

Apparently, this was not enough to convince the client that a code level fix was required.  The solution? Disable custom errors.  The result? No more vulnerability detected by the scanner.

Despite my best efforts, a "clean scan" was more important than bug-free code.  I believe this mentality is caused by a growing "checkbox security" attitude which allows mediocrity to displace excellence.  A "D-" is now acceptable because it's not an "F" -- "At least we passed!"  This checkbox attitude lets stakeholders console each other with "We scanned the app according to PCI 6.6.  No errors.  CHECK!"  Never mind the fact that we all know there's a bug, but we've disabled the error messages that allow the  security tools to see it... 

Security through obscurity at its finest.