A more effective approach has always been to plan your initial  efforts, focus on your primary and secondary assets and analyze the life cycle span of the entire process.

In this article, we’ll discuss some proven methodologies known to efficiently deliver results.

Step 1. Many organizations fail to grasp the essence of VM and tend to regard it as a part of the IT administrator’s responsibilities. Though this may be true for smaller organizations (read very small) but any larger organization must have a dedicated team assigned solely responsible for hunting down and patching vulnerabilities.

Step 2.  Create an index of all IT assets currently owned by the organization, specifically highlighting systems connected to IP networks. This database will act as your ‘Evaluation Base Line’ that will indicate the patching status of your entire inventory.

Step3. Vulnerability management is an ongoing process. New vulnerabilities emerge every instant and require continuous monitoring. Similarly a change in configuration might make a relatively secure system prone to attacks.

Step 4.  Prioritize patch implementations when it comes to choosing in between ease of accessibility and security. Every system can hardened to become virtually impenetrable but at the cost of user friendliness.

Step 5.  Simulate post patch scenarios in advance. New patches can sometimes cause unexpected changes in systems like conflicts with system registry and occasional incompatibility issues.

Step 6. Create a database of all patches. Since computers at an organization are perpetually being changed, formatted or simply being restored, an archive of all patches helps you to quickly cover up vulnerable systems, without having to search through patch releases for individual software all over again.

Step 7. Automate! Integrate easily available patching solutions or updating utilities at your organization to reduce manual overhead.

Step 8. Never assume. Assumptions in security have taught many professionals expensive lessons. A system isn’t safe unless it has withstood an attack. Make a habit of frequently simulating attack scenarios on systems likely to face rogue traffic, you’ll surprised at what your findings!

Act right away!

As much as people like to document their scan results in reports and refer to them in board presentations, do not loose focus on the primary objectives of these results…..Patch those vulnerabilities NOW. It is unintelligent … to say the least, to have discovered vulnerabilities but to leave the patching for a later date. And speaking of documenting, try to maintain a certain degree of privacy with your vulnerability findings while limiting access to your findings to relevant personnel only.

Patching and thinking you are protected?

Patching should only be a part of your defense strategy. Patching generally mitigates risk caused by faulty or sloppy programming codes, which are relatively easy to identify using automated techniques. The trickier aspect of information security involves logical errors, which  arise due to acute lapses in configuration settings and parameters of the myriad of devices present on networks.

Protecting yourself from Zero day attacks…

Zero day attacks are quite understandably the worst fears of any security professional. While you cannot predict what the future has in store for your network, there are certain practices that will minimize the potential of your systems being targeted.

-          Harden your systems

-          Use heuristic protection based Anti viruses.

-          Deny the irrelevant and only allow least privilege to those you permit

-          Finally, educate users to be wary of unsolicited and suspicious email attachments.

A Vulnerability Management System is only as strong as its policies…

The strongest Vulnerability Management programs are always characterized by their elaborate policies. Policies help you regulate the operational effectiveness of your corporate infrastructure. Policies drive your users to

-          Practice better password conventions.

-          Bring in the use of encryption in official emails.

-          Create a realization that security is everyone’s responsibility.

-          Regularize the use of firewalls and antivirus programs.

-          Familiarize people with the risks associated with social media

-          Ascertain the confidentiality of organizational data and prevent instances of data leakage.

Uncertainty amongst employees leads to more dubious behavior. With most of today’s security products designed to counter external threats, how do you keep the EVIL WITHIN from jeopardizing your security and compromising the sanctity of your data?

Recent surveys conducted by (but not limited to) Symantec and Ponemon indicate that employee exodus has also resulted in tons of sensitive data being leaked out as well. The survey conducted around a thousand participants revealed that an overwhelming majority of employees took a copy of their work with them. According to the survey, CDs remained the most popular mode of sneaking out data with confessions from 53 percent of the participants. Next inline were USBs which had been used by another 43 % while 38% said that they had used Email.

While the more benign of the lot may just keep it as apart of their memory, the more enterprising may have other wily ideas.

It is necessary to elaborate that implementation of a DLP does not necessarily imply lack of trust in employees, in fact it’s there to prevent against any accidental losses. Studies analyzing recent data leakages indicate that a vast majority of disclosures are unintentional and may be attributed to the lack of awareness amongst employees. A majority of instances of leakage scenarios can be traced back to lost USB storage devices or stolen laptops. Social networking sites, blogs and the increasing use of wikis is contributing to incidences of both incidental and intentional leakages.

It is under these scenarios that the implementation of a DLP starts to make sense, prevent malpractices, before they can actually hurt.

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.

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!

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 here, here and here.

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).

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.

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.

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.