Archive for April, 2009

Guidelines for Setting Up a DLP

Planning to set up a Data Leakage Prevention (DLP) system for your company? With DLP systems costing as much as they do, its common for security managers to think of these new contraptions as the elixir of all their headaches.

Just before you start attaching too much expectations to your DLP, its better to get an insight of what a DLP system is capable of – and more importantly what its not capable of.

DLP is essentially  targeted at risk reduction, not truly elimination of threats. System admins have to be careful of the nature of security they are deploying, misdirected policies are likely either raise too many false alarms or too little.
Identify your sensitivity areas, categorize possible threats based on your organizational structure. While it may not be very alarming to have some one from the HR to have a list of all your employees, the same list in the hands of someone from, say, the marketing department should be very alarming. Whereas an attempt to copy or email the same from anyone should automatically trigger an alarm.

Hence simpler the policies, the more effectively your system reacts, for example, address personal info of employees in one rule, another for customer credentials, yet another to deal with pricing archives.

Once you have your policies defined, its time to test them and make some fine adjustments as well to optimize your response. One of the biggest hurdles to an effective implementation of a DLP is improperly defined user groups. In a system that relies heavily on your classification of users on the basis of their priveliges, it’s important that you keep the directory structure as straight forward as possible.

And finally, one thing that we can’t emphasize enough on, is to test, test and retest your DLP configurations, these will truly let you gauge the capability of your DLP installation.

, , , , , ,

Acid test your Security with Penetration Testing

By Faiz Ahmad Shuja

This article was featured in the April 2009 issue of CIO Pakistan’s CSO magazine.    


In a cruel world, where even slow portals are not forgiven, the uproar in the event of a security breach is not too difficult to imagine.

Today, with the evolution of electronic commerce, online business presence signifies much more than your proactive business approach. The well being of your IT infrastructure relates to the trust of your customers and your corporate identity.

The advent of sophisticated threats and attacks over the Internet have added to the concerns of organizations globally. Blended malwares, sophisticated attacks, identity thefts, DDoS attacks and financial scams are just some of the predicaments associated with any system connected to the Internet.

Information security personnel in an organization can either learn their weaknesses the hard way by waiting for an attacker from the dark to exploit one of their vulnerabilities or could save their grace with their own trusted team of ‘Penetration Testers’.

Penetration Testing (Pen-Testing) is a practice of testing security measures by emulating real-world attacks on the IT infrastructure in question, pretty much like testing a supposedly bullet proof armor by showering bullets on it.

Penetration testing is considered one of the most rigorous tests of an infrastructure’s security and stability. Testing involves analysis of each access layer, network, system and application, such as from reviewing the application code of a front-end web application to analyzing the possibility of session hijacking attack on the network.

For most of the security audited organizations that we encountered, we found that previous security assessments generally lacked in-depth examination of the infrastructure, especially on the application layer – a high risk zone.

In fact most of the attacks witnessed in last few years heavily rely on the vulnerabilities existing in various web based applications. A compromised web application can grant mind boggling access to a determined attacker. A common scenario is when an organization has implemented a custom application developed by a third party. Such applications can host an array of high risk vulnerabilities.

Considering the very intricate nature of these tests, a common debate amongst management and information security personnel is whether to carry out these testing by in house personnel or hire a third party specialists. In house testing whilst being easy to rely on tends to be  biased in favor of existing management policies (after all they are the ones who built it in the first place). Whereas a third party usually provides harsh, ruthless analysis of your service and sometimes may go to extents that may be more of an overkill.

With penetration testing being declared mandatory by PCI DSS, other security standards are likely to follow suit. Now is a good time to start looking into your penetration testing requirements. In house penetration testing requires dedicated staff and resources along with some vulnerability research expertise. If however you are not thinking of further investments just yet, then a viable option would be to hire an external consultant.

When looking for a penetration testing service always look for a provider with a comprehensive testing procedures comprising of composite testing methodologies covering all layers of your infrastructure. Ask for their vulnerability research portfolios, such as discovery of any vulnerability in a popular application and issuing of vulnerability advisories. This will help you identify if they employ manual or automatic testing techniques during the tests.

An automatic test involves running specialized software that run through your network for common flaws. A manual test whereas involves in depth examination by seasoned veterans. Due to the complexities of application architecture and business logic, sometime it is almost impossible to detect vulnerabilities through automated tools and that is where expert penetration testing consultants come in. Manual examination reveals the presence of backdoors, obfuscated parameters and manipulation of programming logic to compromise platform integrity.

Another aspect to consider prior to finalizing your agreement is to consider the nature of testing to be carried out by the consultant. Generally there are two main types of testing approaches, Black box and White box.

In black box testing, penetration testers act as external hackers with no inside knowledge of the target network. Whereas, a white box test is carried out with extensive knowledge of the target network provided to the penetration testers. This information generally includes details of network topology, IP addresses, operating system versions, application source codes, etc.

The crux of all your tests, the penetration test report, will be an essential part of your future security roadmap. Report is made to provide an abstract account for key security personnel summarizing the weaknesses discovered and followed by a comprehensive description of the testing methodology adopted, phases of implementation and analytical review of the vulnerabilities detected. The penetration test report is the ultimate yardstick of your organization’s current security state. The penetration test report helps you prioritize remedial action for high risk vulnerabilities. Maintaining confidentiality of the report is a must.

Fortunately with the growth of local information security professionals, offering services akin to renowned international consultants, organizations no longer have to bring in foreign specialists at notorious rates. But before you finalize anything make sure you have carried out some background checks on the consultant’s professionalism. Look for customer testimonials and formal certifications such as CISSP, CPTS, CEH, GSEC, GCIA, GCIH and OSCP. Lastly, formulate legal agreements to ensure any vulnerability detected is kept confidential until remedial action has been taken.

Happy testing!

, , , , , , , , , , , ,

Myths and Facts about PCI DSS

PCI DSS is a popular topic among the credit card and financial gurus of industry. A lot has been said and commented upon and some of those are not really true. To really grasp the PCI DSS, one needs to differentiate between many myths that surround it. Here are the five common myths:

1.    Myth: PCI too Hard

“….PCI is too hard, too complicated, too expensive” 

With 12 requirements of PCI DSS, it does seem too hard but in actual, PCI DSS is basic and practical security practice that is not really too hard. Even with 12 requirements, many services and products are available to help meeting these requirements with ease. As for being too expensive, the cost of being incompliant is far more in terms of security attacks and legal fines. 

2.    Myth: PCI is enough Security

“…We are secure because we got PCI” 

PCI is basic security but not necessary enough. There is more to security than just YOU’RE YOUR system is not safe from security attacks unless continuous efforts are made all the time. Assessment and remedies are must since PCI may cover confidentiality but not integrity and availability of data. 

3.    Myth: PCI is unreasonable

“..we don’t know what to do” 

Many aspects of PCI are already common practice. Standards actually permit compensating controls to meet requirement. PCI DSS documents provide details that significantly benefits merchants and processors. Check out PCI for Dummies for more information. 

4.    Myth: Just one tool, product or vendor makes us PCI Compliant

” …I use PA-DSS tools, thus I am PCI OK” 

No, it doesn’t make you PCI compliant. No single product or vendor can meet all 12 requirements. So instead of focusing on just one product, make sure to follow complete security strategy and focus on the big picture instead of just one aspect. 

5.    Myth: Not enough credit cards to be PCI compliance

“..we don’t need PCI compliance since we don’t deal in credit cards much” 

Even if you make just one transaction then you require PCI compliance because it is required for any business that accepts payments. 

So these are some common myths that surround PCI DSS. However, there are more. You can check them out herehere and here.

, , , ,

The Need for Data Leakage Prevention (DLP)

Many years ago, I remember watching a clip on TV about someone inventing a toilet that once locked, would not open unless it senses that someone has used the washbasin first. Interesting and to some extent sickening – just makes you wonder, was it invented as a precaution or a necessity?

There probably aren’t many people out their, who have to be forced to wash their hands after the toilet but considering the stakes – the precaution was worth it.

Putting this in corporate information security perspective, most of our rules have less to do with legislation and more with common sense. Moreover a policy that isn’t implemented tends to remain more of an advice – which tends to be generally disregarded.

Data Loss Prevention (DLP) is a preventative technology, if you’d call it that, I consider it more of an amalgamation of existing little utilities packaged into an integrated software allowing centralized policy control and more importantly policy enforcing.

If you’re fed up being the Dutch uncle on information security issues that is once something appalling has occurred (people usually start seeking an advice once they’ve done the irrevocable). Maybe it’s now time for less advising and more enforcing of things, maybe its time for Data Loss Prevention (DLP).

, , , ,

What’s this PCI DSS all about?

Attackers are modern version of pocket pickers, only more bothersome as unlike pocket picker they not only just steal your wallet but also your personal confidential information. When plastic money i.e credit cards were introduced, they were hailed as a source of convenience and ease. Unfortunately, it proved to be an easy target for scams, frauds, phishing, and other related attacks. To cater that, giants of the credit card industry established Payment Card Industry (PCI) Data Security Standard (DSS) – PCI DSS.

Just as the name suggests, theses are a set of standards to protect from security breaches in credit card payment networks. These standards are governed by a council comprising of American Express, Discover, JCB, MasterCard and Visa. These standards apply to any financial institution, organization, vendor, and merchant that use, store, process, or transmit payment cardholder data.

In some countries, by now businesses must be PCI DSS compliant or else they can lose the ability to process credit card payments and can be heavily fined. In Pakistan, I believe financial institutions must be PCI DSS compliant by 2010. So, it’s the right time to start preparing for the implementation of PCI DSS controls.

To be PCI DSS compliant, company has to follow twelve specified requirements that are organized into six logically related groups.

Control Objectives

PCI DSS Requirements

Build and Maintain a Secure Network 1.      Install and maintain a firewall to protect cardholder data
2.      Do not use vendor-supplied defaults for system passwords and other security parameters
Protect Cardholder Data 3.      Protect stored cardholder data
4.      Encrypt transmission of cardholder data across open, public networks
Maintain a Vulnerability Management Program 5.      Use and regularly update anti-virus software on all systems commonly affected by malware
6.      Develop and maintain secure systems and applications
Implement Strong Access Control Measures 7.      Restrict access to cardholder data by business need-to-know
8.      Assign a unique ID to each person with computer access
9.      Restrict physical access to cardholder data
Regularly Monitor and Test Networks 10.  Track and monitor all access to network resources and cardholder data
11.  Regularly test security systems and processes
Maintain an Information Security Policy 12.  Maintain a policy that addresses information security

Various revisions in PCI DSS have been released over the years and the current version was released in December 2008 October 2008 (Credit goes to Mr. Yousuf Zubairi for pointing out our lapse here – Thanks alot). Many controversies and criticisms surround these versions that I believe, deserve another post.

, , , ,

Conficker.C Pakistani (.PK) Domains

Conficker.A and Conficker.B created around 250 domains per day from which they downloaded the updates or atleast tried to download. Unlikely, Conficker.C creates 50,000 domains per day out of which over 400 are .PK ccTLDs (country code top-level domains) containing only 4-9 characters as compared to 8-11 in Conficker.A and .B.

We have taken out .PK ccTLDs from the list of all domain names, computed by Felix Leder & Tillmann Werner, that Conficker.C will use in April 2009. It’s recommended to sinkhole these domains.

The list of Conficker.C domains for April can be downloaded here.

, , , ,

Copyright © Rewterz. All rights reserved.