Articles
April 2011
From the Desk of the CTO
Continual Security Assessments
How often does your organization conduct a security assessment? If compliance requirements and traditional audit practices are any indication, then the answer is probably “once per year.”
But how often do you make changes to your infrastructure? How about your applications? Is that answer still “once per year?” I didn’t think so. My guess is that you probably answered “monthly” or “weekly”... maybe even every other day.
With an environment that’s in a constant state of flux, how can you possibly keep it secure?
You can start by performing continual security assessments.
I honestly believe that annual security assessments are currently undervalued. They are terrific tools for taking a point-in-time snapshot of your control set and your control gaps. What’s more, a risk-based assessment can help you prioritize your security spend for the coming year, focusing your limited resources on areas that need attention right away.
Once your annual assessment is complete, it’s ESSENTIAL that you schedule smaller, recurring assessments that ask two key questions:
1) What’s changed in our organization’s environment?
2) What’s changed in the global information security landscape?
Every application or infrastructure change brings with it the risk of impacting the confidentiality, integrity, or availability of your business critical systems and data. In addition to a solid change control process, make sure that the information security team has a pipeline into these changes. During the recurring assessments, discuss these changes with respect to your annual assessment. The sooner you align your security controls with the new environment, the sooner you close the window of opportunity for an attacker to exploit that control gap.
Likewise, continual assessments need to address how new and emerging threats might impact your organization. Don’t wait for your next annual assessment to confirm what you knew nine months ago. Stay current, and take the appropriate action sooner rather than later.
The output from an annual security assessment should be a living document that is at the core of your information security program, and continual security assessments can make that notion a reality.
April 2011
Security News
Are Your Users Immune to Social Engineering?
Firewalls. Antivirus. Antispam. Web Access Gateways. Intrusion Detection Systems. Encryption. Data Loss Prevention. Et cetera. When it comes to technical controls and countermeasures, we’ve got our stuff together. We’re IT security professionals. It’s what we do.
But I have yet to see a technical product capable of preventing our end users from sharing credentials with someone impersonating a help desk employee or clicking on a link in an email from a total stranger.
So what can we do to protect those users from social engineering attacks?
Realize that most people just want to be helpful. That said, the information security team should deploy and maintain a core set of technical controls to protect users from themselves. Start with this checklist:
· OS Patch Management
· Application Patch Management (Adobe, Java, Flash, etc.)
· Antivirus
· Host-Based Firewall
· Web Access Gateway
· Egress Filtering in the Firewall
· Appropriate Access Controls (Principle of Least Privilege)
Phishing emails will attempt to lure users into visiting websites hosting malicious content, or perhaps prompting users for their login credentials. By implementing the layered controls outlined in the checklist above, you can significantly reduce the likelihood of a successful exploit.
Most importantly however, EDUCATE YOUR USERS.
Annual security awareness training, combined with recurring reminders (e.g., security emails, newsletters, or posters) can go a long way toward determining whether or not your user clicks on that link or hangs up on that impostor and contacts the security team.
Finally, validate your efforts. Perform social engineering tests throughout the year to gauge the effectiveness of your technical controls and training efforts. Don’t leave anything to chance.
April 2011
Army of One
Epsilon Aftermath Will Expand Seriousness of 3rd Party Verification for Suppliers -- Is your firm ready?
Jacadis helps businesses prepare and respond to security questionnaires and audit requests from their usually larger customers. We also are the audit and assessment team for some firms who choose to use external resources to review their key vendors' security.
Frankly, as breaches Epsilon isn't a big of deal. No protected information, just names and email addresses were taken. And more sophisticated attacks have come and gone in the press largely unnoticed.
Epsilon has received more attention than the more impactful breaches in part because it touched so many people. Non techies are talking about it. We believe that buzz is going to find its way into the executive suites and audit teams of big companies and boost the rigor and frequency with which larger firms test, prod, and assess their supply partners.
In fact it isn't just us that thinks that.The Wall Street Journal reported in Insulating Your Firm from Third Party Breaches that:
Experts suggest that companies that outsource technology services take some of the following steps:
- Make sure the vendor has a recognized certification for information security, such as ISO 27001 or SAS 70 Type 2, granted by an accredited auditing organization such as the International Standards Organization;
- Sign agreements that oblige vendors to undergo regular audits by third parties, at least annually. Auditors should test software (especially software that can be accessed via the Internet) and hardware as well as people, to ensure that vendors’ employees themselves don’t fall prey to scams;
- Make sure vendors assume liability for breaches that affect customers and end users; and
- Make contingency plans with the vendor so that neither is caught by surprise in the event of a security breach.
Management consultants and corporate governance experts are providing similar advice to their Fortune 2000 and similarly sized customers. These recommendations have been around for several years, however, the buzz from Epsilon has the potential to fuel the recommendations to reality.
This will impact you if you answer yes to any of the questions below:
- Your business is part of the supply or services chain for larger regulated firms. We see most of the third party verification activity from firms that have regulatory obligations to HIPAA; PCI, GLBA or other financial privacy rules, or Sarbanes-Oxley. We have seen these type of firms apply the highest security and privacy standards to their vendors even if their vendors don’t process confidential or protected information. Do you provide services to these types of firms?
- Your business provides a service that includes considerably volatile information. If, for instance, you process non-protected personal information but it is somehow seen as critical to your client’s business or it’s relationship with its customers this might apply. Or, if, for another instance, you process company confidential information such as trade secret related information. Do you provide services to these types of firms?
- Firms in the supply chain stack. You may not be doing business with a regulated firm, but you may be providing services to firms that provide goods or services to firms that provide services to regulated businesses. You know what they say about it rolling downhill. Are you at the bottom of a supply chain?
Take action
If you answered yes to any of those questions we suggest the following:
1. Look at your customer agreements with firms in the categories above.
- Do any of those agreements place obligations on your company to protect your client’s information in a certain way?
- Do they have the right to audit?
- Have you told your IT team about these obligations?
- Are you prepared to meet these obligations?
2. Sit down with your technical leadership and discuss:
- Are we secure? Vulnerable? Do we follow a best practices approach to information security? Which one?
- Do we routinely check through tests, assessments, and/or audits our answers to the questions above?
- If we got an auditing letter from an existing customer would we be ready for the audit in a week? a month? 3 months?
- When the auditor arrives do we have documentation that defines our security programs values (policies), details the routines we follow to meet those values (processes), shows that those routines are being followed (logs, action reports, scorecards, etc.) and that our staff is aware of their obligations (awareness training)?
- If we committed during the sales process with a new customer to do certain things to secure their data did IT and the others in the company responsible for delivering on that obligation have a hand in the answer? Are we overcommitting?
- Are we managing security well enough that we can create a competitive advantage over other firms in our class? Can we use that advantage to build new business?
If your business provides business to regulated businesses upstream in your market we recommend you keep asking these questions until you feel comfortable with the answers.
March 2011
From the Desk of the CTO
They want to connect WHAT to the corporate network?
Smartphones and tablet devices are making their way into the workplace. Unfortunately, the decision to connect these devices to the corporate network is often made without first consulting the IT department. The worst part is that the information security team is frequently kept in the dark for fear that they would tell the business no.
But does security really need to say no to this request?
Of course not! The security team should be helping the business find a way to do what they need to do securely. Companies that embrace mobile technology in a safe and secure manner will reap the benefits that come from the increased connectivity and mobility. The key to avoiding a security incident or data breach related to these devices is in the security details.
A few questions that the security team needs to ask the business:
· Have we documented an acceptable use policy for mobile devices?
· What information do we need to include in that policy?
· How are we going to keep track of these devices?
· What steps do we need to take to secure devices before they connect?
Permitting mobile devices in the workplace should be a business decision based on a clear business need. Before that decision has been made, engage the security experts in order to ensure that you deploy those devices safely. You need to involve the right players from the very beginning if you want to securely integrate mobile technology into your business processes.
Remember: It’s better to end up in the news for a record-setting quarter, and not for a security incident that could have easily been avoided.
March 2011
Security News
Mobile malware is here…
Earlier this month, a variant of the Zeus Trojan was discovered on Blackberry mobile devices. Zeus was created with one purpose: to grant criminals access to a victim’s bank account by compromising their online banking sessions. Although Zeus has been around for years, the fact that it’s moved to the mobile device should have you asking one question: What am I doing to protect my users?
Whether you’re responsible for securing 5,000 mobile devices across three continents, or whether you’re the go-to IT person for your friends and family, you need to be prepared to address threats like mobile malware.
First and foremost, educate your users. Teach them how to exercise caution when checking their email and browsing the Internet, especially from their mobile devices. Consider installing an alternate mobile web browser if the default browser is riddled with security holes.
Second, introduce your users to mobile security applications. For the home user, Lookout Mobile Security provides a free security app for Android, Blackberry, and Windows Mobile devices. While this is a valid solution for the home user, it doesn’t solve the problem of malware on mobile devices connected to the corporate network.
Centralized mobile device management is the key for protecting mobile devices in the workplace. Once you deploy a mobile device management solution, you can begin deploying enterprise-grade antimalware solutions to your mobile devices.
Having the ability to centrally manage security policies and monitor mobile endpoints is key if you want to protect your end users (and your corporate assets) from malicious software.
March 2011
Army of One
Doing More With Less
If you’re an information security professional, chances are the words “unfunded mandate” have come up more than once during your career. Whether it’s compliance with regulations like HIPAA/HITECH and PCI, or the deployment of a new application or technology to enable the business, the available budget never seems to be enough to cover the work on the security team’s plate.
With so many priorities competing for so few resources, you’re probably asking yourself, “Where do I begin?”
Three words: Security Tool Optimization.
Most information security organizations have grown organically. Chances are you started with a firewall, something to keep unauthorized users from accessing company resources. Then you added antivirus, to prevent business operations from being interrupted by a virus outbreak. Over time, you probably added an anti-spam solution, an Internet access gateway, patch management, intrusion detection, encryption, VPN, a vulnerability scanner… the list goes on and on.
Trying to maintain all those security point solutions is a nightmare. You’re spending all of your time keeping these point solutions up and running, when your time would be better spent analyzing and addressing the specific risks that could have a significant negative impact on your business.
It’s time to take a step back and take stock of your environment, approaching the process with a fresh perspective. Realize that your collection of security tools isn’t a burden. It’s an opportunity.
Your company values information security enough to invest both capital funds and operating expense into deploying and maintaining security systems. So what would happen if you combine three, four, even five of those point solutions into a single system? You just might free up enough funds to:
· Hire another security analyst.
· Address a gap in your current control set by investing in a new technology.
· Send your team to training.
· Prove to the CIO that security isn’t a financial black hole.
Doing more with less is par for the course when it comes to information security. Optimizing your existing information security toolset is the first step you need to take in order keep your security organization strong.
November 2010
SIEM Innovation
The value of SOC/NOC convergence
CLICK HERE to register for the SIEM innovation – the value of SOC/NOC convergence Webiner
While Security Information and Event Management (SIEM) has widespread adoption by many organizations, a new and better approach is needed to manage increased complexity, threats and regulations. We are excited to introduce what we feel is an evolutionary and innovative security, data center and cloud monitoring platform.
AccelOps delivers robust, out-of-the-box SIEM functionality for those seeking or migrating from conventional SIEMs such as Cisco MARS. Beyond that, the platform cuts across security and network silos and infrastructure technologies to provide end-to-end visibility, proactive monitoring, expedited response and service insight - benefiting the security professional and the entire IT organization. You’ll have to see it to believe it.
Enterprises want to optimize security and network operations within their IT organization. We’re not saying security expertise and tasks have diminished value. To the contrary, information security is vital. But the realities of operational complexity, sophisticated threats and a myriad of regulations demands that information security professionals gain more automated oversight and access to relevant operating details. Coincidently, we see the same requirements from networking staff.
The justification to advance security and network operation convergence is often based on improving visibility, economics, responsiveness and compliance. To improve data center management capacity and lower costs, our clients are looking to maximize their investment in persons, tools and techniques.
By aligning teams, refining processes and leveraging better tools, organizations will see greater operational agility and collaboration. By advancing or consolidating tool portfolios, companies can better justify expenditure while actually saving both capital and operating expense. Furthermore, IT is being measured on meeting service levels. As such, appropriately responding to threats and problems, whether security, compliance or performance, requires an understanding of business impact.
The big drivers for SOC/NOC convergence are clear:
- proactive management
- faster root-cause analysis and lower MTTR
- increased skilled resource capacity
- increased IT service reliability
- improved operational efficiency
- job enrichment for the security and network IT professional
AccelOps delivers a seamlessly integrated data center monitoring platform that addresses the above SOC/NOC convergence requirements. The platform not only delivers complete SIEM functionality, such as real-time correlation, historic analysis and compliance automation, but also provides the next logical SIEM evolution. A plug and play, scalable virtual appliance solution that gives the information security professional and network team a single pane of glass for monitoring all aspects of data center and IT operations, end-to-end and in the context of business services. You have to see it to believe it.
Witness the AccelOps breadth, depth and value firsthand
CLICK HERE to register for the SIEM innovation – the value of SOC/NOC convergence Webiner
August, 2010
From the Desk of the CTO
Black Hat USA 2010 and the value of Prevention, Detection, and Response
CLICK HERE to register for the Jacadis BLACK HAT 2010 Webinar, presented by Jacadis CTO Simon Herring
Woven through many of the sophisticated and highly technical sessions at Black Hat USA 2010 was a very simple truth -- the bad guys really do know your systems and applications better than you do. Yes, your IT team knows how to install, configure, and support your business software, but cyber criminals know how to analyze it, break it, and make it do what the software manufacturer never imagined. By analyzing memory, file access, and network activity, criminals reverse engineer software to reveal flaws missed by hasty software production schedules and minimal software security practices. It’s this level of innovation, as well as motivation for profit, that allows them to slip through anti-virus, Data Loss Prevention(DLP), and Intrusion Prevention Systems (IPS).
So how do you keep pace with the type of adversary described at Black Hat? It’s a three-fold process. First, anticipate (or expect) security incidents. Applications, network, and systems change. Hosts are moved, firewall rules are modified, and upgrades happen as a part of normal IT growth. Even under the best of conditions, unintentional mistakes are made that open systems and data to unauthorized access. Have you ever relaxed a firewall rule to troubleshoot connectivity or removed stringent wireless settings to support an important business guest? If it’s not an IT error, there’s always one or more employees willing to be “Phish food” despite stringent web filtering and security awareness training. Regardless of how it happens, it’s best to recognize the inevitability of security safeguards not working as expected.
The second step is to know when an incident happens. 100 emails in 5 minutes from your IPS alerting you to “network reconnaissance” is not an incident. It’s worth looking into, but it’s no reason smash the glass and sound the alarm. Similarly, 1000 root login attempts or numerous failed requests for “/etc/passwd” on your Microsoft IIS web server is hardly worth critical inspection. After all, it’s an IIS server and these are Unix attacks. What about a root login to your AIX server followed by a privileged query on your DB2 database? That may be a normal practice in your environment, but what if it happens at 3AM and is followed by numerous outbound FTP transfers to Estonia? I’d say that’s a data breach. The good news is this activity can be detected automatically and even blocked. Achieving this level of defense can’t happen until you know what are acceptable business logic/rules for your company.
Finally, know what to do when failure happens. Some incidents are low impact and do not require a high degree of effort to respond. Others incidents are more complicated. In fact, you may not really know what’s happened. What you do know is data has been accessed and transferred at an odd hour, but that’s it. Yes, it’s suspicious and it sends chills down your spine, but what you do next will either illuminate the details of the breach or irreparably damage the ability to respond in a way that protects your customers and co-workers. During an incident is not the time to figure out what you’ll do when a breach occurs. It’s too late. You can, however, run periodic exercises that simulate an incident. Create and test safe threat scenarios that simply shouldn’t occur unless it’s a breach. Use these tests to assume prevention has failed. Then check your logging and monitoring systems to see if there’s any way to recreate what happened. This will show you where your high risk detection blind spots are. Use this valuable information to tune your detection safeguards.
Prevention, detection, and response – it’s a cycle. The sophistication of today’s threats means you must expect a security incident. It may be minor. It could be massive. Either way, you must know when it’s happened. Don’t simply rely on building a taller castle wall; know when a taller ladder has risen above your defenses and allowed the enemy in. Test this when the timeline and impact is your to control, not the adversary’s.
CLICK HERE to register for the Jacadis BLACK HAT 2010 Webinar, presented by Jacadis CTO Simon Herring
August, 2010
Security News
Credit card data – easy hunting
It’s not often I read about a payment card fraud spree only affecting 200 people. Usually I read about thousands of people, if not millions of affected individuals. So what makes a recent crime spree in Sanger Texas (pop. 7950) so newsworthy? While the details are still unclear, what is known is that a server used to process credit card payments for a local Sanger business was compromised. With reports of fraudulent charges popping-up all over the US, it’s also clear that data belonging to Sanger residents was sold and copied to fake cards. Nothing out of the ordinary so far—steal the card data, sell it, duplicate it, then make fraudulent charges.
If this spree is anything like other incidents involving small businesses, the hackers didn’t train their cross-hairs on Sanger residents or the mystery store. This store was simply a target of chance. Let me explain. Have you ever walked into a small local business like the corner pet store or the local pizza joint and observed the cashier surfing the web? Yes, surfing the web on the same Windows XP system that processes your credit card transaction. While you pick your small-to-medium business (SMB) or enterprise-sized jaw off the floor, keep in mind that shops much smaller than yours may only have one server. And they use it for everything. It was only a matter of time before Billy the cashier unknowingly sprung a trap that was set weeks or months in advance. The hunter didn’t even know Billy. If he’s like me, he’s never heard of Sanger, Texas! He simply set a trap and waited for anyone to spring it. The victim could have easily been a home PC user. In this case it just happened to be a credit card processing server. Jackpot!
This is not an isolated incident. While I was at Black Hat USA 2010 in Las Vegas, a forensic investigator shared the details of a similar incident at a Florida night club. He explained how malicious code was installed and used to copy every credit card transaction made at the club. This information was saved, encrypted, and transmitted each day to remote hackers. This is all pretty standard fare in the world of Crimeware, but why a Florida night club? Why Sanger, Texas? That’s the easy part – they were unwitting game.
Traps like Cross site scripting (XSS) and HTTP drive-by are set every day. Sprung traps, or hacks detected by antivirus and IPS, are replaced and newer, more innovative hacks are created and placed in unsuspecting places. They could be hidden in a partner, customer, corporate, or social media website. What prevention, detection, and response steps are you taking today so you’ll know if an employee sets off one of these traps?
August, 2010
Army of One
Why INTELLIGENT logging should be a "must have", not a "nice to have"
So the Verizon 2010 Data Breach report (
DBIR) is out, and lo and behold, a full
86% of all the breaches that Verizon and the US Secret Service investigated had evidence of the breach in the logs. 86%! Almost
9 out of 10 of those breaches might have been detected early enough to not be mentioned in the report.
To quote from the report:
"The signs are there; we just need to get better at recognizing them"
I don't know about you, but avoiding "CNN moments" like this would be pretty high on most CEO and CTO's goals list. Log Management is not rocket science, but megabytes or even gigabytes of log files require intelligent tools and
proper tuning to be useful. We recently installed Prism Microsystems
EventTracker software at a client of ours and in 3 months it's captured 435 MILLION log entries, and they're not a large enterprise, but what I would consider a small to mid-sized firm with fewer than 200 workstations and under 50 servers.
No one could or should be expected to manually review even a small percentage of that log event load and simply capturing the data does nothing more than give you a place to look AFTER you've suffered a breach and are doing your forensic review. "Great", you'll say, "the evidence was right in front of our eyes". Well, buried in the log files, just waiting to be uncovered…..
Uncover them using a well-tuned Log Monitoring tool like
EventTracker. Learn what "normal" is on your network and alert when something anomalous happens. If it's a false alarm, learn from it and tweak the settings. It pains us to visit clients who have Log Monitoring and have the alerts go into someone’s email box to be looked at "when there's downtime". Guess what folks, there's no such thing as "downtime" anymore. Inevitably a rule gets setup in the email to put those "alerts" into a folder and next thing you know the folder has hundreds or thousands (more?) of unread messages. “When there’s downtime” becomes
after the breach.
At minimum you should be concerned with the following "families" of events that generate log entries:
Logins/Logouts: You need to know login failures, login success, login attempts - especially of privileged accounts and especially when there are multiple occurrences. Should someone in Payroll ever log in at 3am? You need to know that!
Changes: Added and Removed users and more importantly administrator accounts. Password events - learn what's normal.
Network Events: By this we mean more than just rogue wireless networks. You want to look for those events that just don't follow your baseline. Why is my database connecting to China? A good log monitoring tools will "learn" what's normal and alert you when something happens that doesn't follow the historic trends.
July, 2010
From the Desk of the CTO
Make stolen data unusable
Hardly a week goes by without hearing about a data breach of some type. Whether it’s a lost or stolen laptop, a misdirected email containing medical data, or a penetrated database that stores personal information, they all share something in common – the container within which the data was stored was not encrypted. Could data theft/loss and the ensuing breach notification the law requires be prevented with something as simple as making stolen or lost data unusable? Yes, it can.
My entire laptop hard drive is encrypted. Client data is stored on a separate encrypted volume protected by an exceptionally long password that is different from my pre-boot authentication password. If my laptop is lost or it’s stolen, the sheer inconvenience of not having a laptop will significantly outweigh my concern for data loss. You see, while my laptop and the data it contains is no longer in my possession, the new owner also cannot use any of the data on it. I’ve made the data unusable.
The devices that pose the greatest risk are those that are both a) mobile, and b) have access to, or store restricted data. Laptops and backup tapes are the most common. In fact, if you look at the statistics from DataLoss DB, it’s clear that these devices are the source of millions of lost identities. For around $70 per laptop, however, the need to disclose the theft or loss diminishes significantly. With the confidential data encrypted, you’ll know this information cannot be used to commit fraud. This is a key point in state laws that govern when breach notification is required.
Make stolen data unusable -- there’s nothing else that yields that greatest risk reduction for the dollars spent.
July, 2010
Security News
Prevention safeguards will fail
History will record Albert Gonzalez as the criminal mastermind behind the data breaches at TJX, Hannaford, 7-Eleven, and Heartland. JC Penny (JCP) was also involved in the data breaches, but remained on a list of unidentified retailers before its name was finally disclosed. Court documents surrounding JC Penny’s involvement as “Company A” contain a wake-up call for organizations that store, forward, or process sensitive information. First, JCP was breached and didn’t know it. Second, the Secret Service notified JCP of the breach.
It’s common in security conversations to hear the statement, “We’ve never been hacked.” We politely counter with, “How would you know if you were?”, a question that is answered with silence. To be confident that your data has not been breached means you know how it’s used, who uses it, when it’s used, from where, and the locations it’s stored on your network. Even then, the data can still be stolen using very sophisticated techniques. While this may sound quite depressing, it underscores this axiom: prevention will fail, so plan for failure.
No doubt, JCP and others penetrated by the Gonzalez crew, all had the traditional safeguards in place. Whether it was due to improper implementation, configuration, administration, or the skill of their adversary, these safeguards failed. When this happens, it’s the role of detection and response to catch business logic and security violations. These events should be logged, an alert fired, or an event written that’s automatically captured in a report the following day. After action review and response is far better than no action at all, or worse, notification by the Secret Service.
July, 2010
Army of One
Plugging data leak holes with egress filtering
Your Internet firewall allows external systems to communicate with a small number of internal company servers. This allows customers and partners to send you email, view your website, or share files over FTP, for example. Who can access your Internet systems is controlled by your inbound (ingress) firewall policy. This same firewall also has the ability to restrict outbound, or egress, connections. By default, however, most firewalls allow any internal system to connect with any external host, using any communication method. This certainly makes it easy to use the abundant resources of the Internet, so why restrict outbound access? The answer is at least two-fold:
-
To reduce the risk of data extrusion. Cyber criminals steal data and sell it. But before they can make any money, they have to get it off your network. If your default egress policy allows “anything outbound”, then you’ve made the task of transferring the data very simple. On the other hand, if you only allow certain communication methods from the inside to the Internet, you’ve complicated matters for the cyber-intruder. He’ll need to find a different way to get the data out. Even better, he might make a little noise as he searches for a communication path that’s allowed. This should standout like a sore thumb. For example, if you don’t allow outbound SSH from users, then any attempt to Secure FTP the data out will be blocked. If you have a log management system (LMS), you can create rules that watch for blocked egress traffic, a clear sign that something isn’t right. This leads to the second point.
-
To detect business logic violations. There are certain things that should and shouldn’t happen on your network. All the legitimate ways your departments, staff, systems, and applications work together is known as your business logic. It describes the way things “should be.” Once you know your business logic, you can use your firewall to block and alert when these rules are violated. For example, everyone internally may be allowed to access the production database, but the database itself should never initiate an outbound connection to any external Internet hosts. If it does, it might mean the database server is compromised and the intruder is attempting to transfer data. With an egress filter in place, not only will this be blocked, but an alert should also be generated, giving you time to investigate proactively.
Egress filtering is a top recommendation when we perform network security assessments or penetration tests. A default outbound “any” firewall policy is too risky these days. We know first-hand of clients that could have prevented data loss simply by blocking outbound connections from internal servers. Simply blocking and alerting on egress connection attempts from internal databases could have tipped-off the administrators and potentially stopped the breach in its tracks. So take the time to understand your business logic, then implement this no-cost security safeguard to help keep sensitive data from leaking through obvious holes.
The subject of manual “code review” came-up during a web application security class I was teaching last month. Considering I was in a room full of .Net developers, this subject was naturally on the agenda. We had spent several hours discussing how to hunt for OWASP flaws using automated black-box scanning. As a group, we explored how automated black-box scanning can be a rapid and cost-effective approach for finding low-hanging fruit exposed to attackers. But I also underscored how there is no substitute for code level reviews. It was here that I paused and asked to what extent were code reviews being performed. Silence… then more silence…awkward. After 30 seconds, someone began opening-up.
Like other organizations I’ve worked alongside, their code review placed most of the emphasis on functional testing and the end-user experience, with the “hope” of finding security flaws during quarterly web app scans and annual penetration tests. Someone also mentioned their perimeter web app firewall (WAF) and how it could help sanitize user supplied data and enforce security policy. While these are valid methods for finding flaws and keeping attackers from exploiting them, in front of this group it sounded more like a reason to skip security-focused code reviews. Thankfully, this was not the case -- timing and resources was the real issue… not surprising given corporate demands to add more features, to code faster, and keep up with competitors.
Finite time and infinite commitments pose a serious challenge to many development teams. This team was no exception. Asking them to put eyes on their code seemed like a tall order, but as a security professional that finds, exploits, and helps companies fix flaws that could be prevented, I had to push. And while I couldn’t change their workload or give them 27 hour days, I did offer these tips to help integrate more security into their code review process:
Have a standard and use it. A standard removes opinion from the code equation. This is especially useful if you have a code security “know-it-all” that can’t explain his/her coding decisions without statements like “it’s secure, trust me!” I say trust, but verify – the OWASP standard is a great way to support that. As a vendor-independent, community driven, and international project, OWASP is the de facto standard for some of the brightest development minds and largest organizations around the globe.
Start code reviews early. I’m not talking about beginning your code review 7AM versus 4PM, though you may need a couple of weeks of that (or more!) to work through your code. No, by early, I mean performing code reviews early and frequently within your SDLC. If you wait until later, there’s sure to be more code dependencies, which complicates the process of fixing the code. This means more time and cost, something organizations don’t have and can’t afford.
Perform smaller code reviews. A code review can seem daunting because it’s easy to get lost in the magnitude of the entire application. Given the option to choose an easy task or a difficult one, most overwhelmed or moderately busy folks will chose the easiest one. This is especially true if your code passes data through a dozen or more functions that crosses several trust boundaries. You can make the code review easier if you break it into smaller pieces. In other words, don’t try to swallow the whole cow in one bite!
Prioritize based on sensitivity. When time and resources are an issue, perform code reviews against areas that store, forward, or process sensitive data like financial data and personal information. Places where input is supplied from untrusted sources deserve the greatest attention first. Work through the OWASP Top-10 for 2010, targeting sensitive functions first. This risk-based approach is easy to justify and returns the greatest security bang for the effort spent.
Leverage reliable technology. If you give these steps a try, but still find your process hurting, then consider automated code analysis tools. There are several options available, from software the runs right in your IDE to SaaS solutions that let you upload your binaries for static analysis.