David Robert's -castlebbs- Blog

To content | To menu | To search

Wednesday 21 April 2010

McAfee DAT 5958 deletes svchost.exe

http://www.incidents.org/diary.html?storyid=8656 Signatures update 5958 locks out Windows XP SP3 clients deleting or putting in quarantine the file svchost.exe.

It is definitely not the first time an antivirus delete a critical file on an operating system (eg. AVG removing user32.dll, Symantec update that affected millions of PCs or BitDefender update that caused 64-bit Windows machines to stop working).

Looking at the different posts on various mailing-lists, it appears that some people now need to manually fix up to thousands of PCs depending of the size of their network.

It's time if it's not already done to review your antivirus procedures to include testing and deployment strategies: all signatures won't be deployed on all PCs at the same time. As well as documenting the process you need to follow if you have a new virus that is not detected, you need also to document what you can do if you have a false positive. And... keep your antivirus vendor support contact numbers up-to-date in case you need them!

If it's too late: http://vil.nai.com/vil/5958_false.htm

Friday 12 February 2010

The three most important security policies

What are the top 3 most important information security policies a company can have?

This question was asked on Linkedin and I found it very interesting to read the different opinions given. Based on the answers, I think it is possible to guess differences in people approach of security policies. I found for example, that reading the answers, you can figure out if the person is technology or process minded.

My answer reflects my opinion regarding Information Security. I think that technology is obviously essential to protect information systems. However:

  • without a strong governance structure...
  • ...driving a security program...
  • ...supported by a consistent set of security policies...

... technology can be a waste of money. The cursor should be put somewhere between technology and governance. If it positioned too near technology you will experience these example of issues:

  • No authority to enforce a security requirement (eg. You need to install a great security product on the servers of a new project, but the project manager doesn't want it to be installed, he has the final word because this new application needs to go live as soon as possible). 
  • No consistence in the application of security across the information assets (eg. who care about the security of the old mainframe!, you prefer working on the security of your new virtual infrastructure!).
  • No strategy or alignment with business current and future objectives/initiatives (eg. You keep working on preventing the blue screen of death with the new Microsoft security patches whereas your company plan to acquire one competitor, just connect both networks directly and didn't think someone should be concerned by security).
  • You have many firewalls, intrusion detection systems, proxies, anti-virus, but programmers don't have any secure programming standards and web application programmers have never heard about OWASP.
  • You have many firewalls, intrusion detection systems, proxies, anti-virus, but you are still ensure that you will be aware of an attack because you don't have time to review the logs and you are not too sure if the alerts work.
  • ...
Well, actually I could do a very very long list, it could be funny though, I may try to contact the MITRE to propose a new enumeration: Technology focused security drawback enumeration (TFSDE) :-)

Well, as you probably understood reading these few lines, I am more that convinced that security policies are essential. Policies establish, but also demonstrate governance. I am convinced about the essential need of security policies, but for the right reasons, not to tick a box and have my number of issues decreased when the auditor comes back. That's unfortunately still the main driver for policies and information security in general. 

My Answer to the question:

What are the top 3 most important information security policies a company can have?

This is actually a very good question, and any security professional has to review policies, and needs to prioritize his work. So it makes sense to find out where to start.

I like the work done by Thomas R. Peltier trying to categorize policies in three tier:

  • Global policies (Tier 1)
  • Topic-specific policies (Tier 2)
  • Application-specific policies (Tier 3)

The CISSP describes as well 3 classifications of policies that matches more or less the one from Mr Peltier:
  • Organizational or Program policy
  • Functional, issue specific policies
  • System specific policies

As I have never seen two companies having the same set of policies (even if in a way of another they address the same things), I find it useful to first identify what category they are from.

If you see the set of policies like a pyramid, the policy at the top is the most important and the one that needs to be reviewed first. This is the one in the Tier 1 (Peltier's classification) or Organizational policy (CISSP classification).

Let's call it the "Organizational Information Security Policy" at the top of the pyramid. This policy normally lays out fundamental things like
  • Governance structure for security
  • Senior management commitment
  • lays out strategic and tactical security program
  • Define roles and responsibilities

I like this policy to be easy to read as a reference document for all employees. I like to keep it short (4-5 pages max) I would definitely review this document first. 

The next one I would look at is the Asset classification policy. It needs to be really crystal clear to the company what assets need to be protected, to what extend and who is the owner.

For the third one, if you are responsible for Business Continuity, I would say the Business Continuity Management policy. If this is out of your scope, my third one would be Acceptable use policy.

I definitely think that information security is more about strategy and senior management commitment than trying to address it from the technology requirements, that's why I would definitely start reviewing, updating and have the Tier 1 policies signed off again.

Wednesday 3 February 2010

IBM i security

IBM i is the operating system (formerly known as i5/OS or OS/400) that runs on System i hardware (formerly known as iSeries and AS/400). System i was the IBM mid-range of computer systems. IBM now offer IBM i on their new range of computer systems: Power Systems.

IBM i is used by many industries and generally host the organisations' critical data and applications. Given the classification of the data that is stored/proceeded on those systems, ensuring a high level of security is paramount.

Mid-range computer systems and mainframes has gained a reputation of being very secure. They are known to be secure by design (compared to Windows and Unix operating systems). This belief is generally shared between IT professionals and auditors. However, few security professionals and auditors are familiar with these systems and a comprehensive assessment of these systems may be overlooked.

The company Powertech did a survey of around 200 system i servers (many fortune 100 companies). The result is amazing. Looking at this reports, it seems obvious that the security of those systems should be getting more focus:

  • Almost 10% of enabled user profiles have default passwords. Over half the systems in the study have more than 15 user profiles with default passwords.
  • Too many users have high privileges over the operating system
  • Weak password policies
  • Lack of adequate controls over data: at the object level (platform and database layer) the majority of users has access to any data, hence breaching the need to know and separation of duties basis.
  • 65% of the surveyed systems have no logical access control over network access: one can download the content of a database without any audit log and control at the network layer. Because of the issue described above on object level access control, on 65% of the systems audited, virtually any user can extract or modify any data from database tables without any auditing logs or restrictions. No needs to be a wizard, a simple ftp client or the excel add-on provided with the IBM Client will get the data for you.
  • 18% of the systems have no auditing features activated at all.

What is really interesting is that the vulnerabilities highlighted here are very basic things: Trivial passwords, generic accounts, access control, log/monitoring, no hardening of the security settings etc. All recipes that are used on micro-computers and that are now mature should be applied on IBM i.

Network access control and auditing

Historically, the only way to access those systems was a dumb terminal. Access control was done restricting the user's menu on the terminal. There were not many paths to the database or platform (operating system) layers. There was no real need to apply a consistent object-level access control policy, the only way of accessing the data was through the menu.

With TCP/IP and network connectivity, there are many more points of entry to the data. Ensuring the effectiveness of these controls is obviously more challenging. 

Importance of data classification policies

One of the conclusion that can be reach reading this report is that there is obviously a breach of the security policies of most organisations when it comes to security of there IBM i systems. I believe that almost all fortune 100 companies have information security policies. They just forgot to enforce them for their most critical systems!

This highlight the importance of having sound data classification policies (ISO/IEC 27002 7.2.1 - CobiT PO2.3). The result of this study shows clearly that inappropriate security level is applied on many IBM i systems assessed during the survey - I take the assumption that they proceed critical data. The implementation of a classification and handling policy force the company to identify where is their critical data so this is less likely that an information system is left overlooked by security professionals and help the auditors in defining their risk-based audit strategy.

Regardless of the technology used (mid-range computers, mainframes, micro-computers), the level of security has to be applied in proportion to the value of the data to be protected. Most of the companies have patch management procedures, hardening guides, vulnerability management programs but surprisingly enough, these don't often apply to mid-range and mainframes

Reference

  • I The survey can be downloaded from the Powertech website
  • I also strongly suggest that you read John Earl's article on auditing iSeries systems published in the ISACA journal: 
http://www.isaca.org/Content/ContentGroups/Journal1/2008/jopdf0801-auditing-ibm.PDF
  • IBM i Market
ftp://ftp.software.ibm.com/common/ssi/sa/wh/n/pow03032usen/POW03032USEN.PDF 

Friday 18 September 2009

Virtual server deployment spanning security zones

Following a question on the cissp mailing list on the risks of virtual server deployment spanning security zones, here is the answer I posted:

Vmware has released a best practice guide about DMZ virtualization. I don't know if your project is with vmware, but I suppose that most of this document is still valuable even with other virtualization tool.

http://www.vmware.com/files/pdf/dmz_virtualization_vmware_infra_wp.pdf

Basically, I think that any option can offer the same level of security but involves different skills and amount of work to mitigate the potential vulnerabilties.

In the second and third option of the document, guest systems from different DMZs are hosted in the same host server. These options can create vulnerabilities mainly because of the increasing complexity that can lead to misconfiguration. There is also issues to enforce separation of duties since the VMWare administrator can modify virtual network settings.

The points above can be mitigated but involve more requirements than the solution with physical separation of trust zones.

With DMZ virtualization, it is even more important that the below is done and this will be very depending on the level of maturity of Information Security and IT in general in each organisation:

  • The relevant IT people should be well trained on the virtualization tool the company uses
  • The VMware systems have to be hardened following best practices, Management zones should be connected on a separate network that is only available to the relevant people.
  • Vmvare patches have to be applied in a timely manner (this can be an issue since all guest systems may need a reboot)
  • Regular configuration audit have to be done to ensure that no misconfiguration has been introduced
  • Stringent change management must be in place in the organisation and no change to the virtual infrastructure should be done outside the change process
Virtualization if far from a being a new toy. This is a great technology that can decrease costs and can offer great DR strategies. This is likely to be a sensitive subject in each organisation and the result of the risk analysis should be well detailed. I think the points above can be used in doing the risk analysis. For example in a company with undersized IT teams, with poor change management process, I wouldn't recommend the DMZ virtualization option (depending on the impact obviously).

Monday 4 May 2009

Compliance automation

Saturday 19 April 2008

Are you linkedin ?

I subscribed to the professional network linkedin.com. It's the first time I register to this kind of website and I have to say that I found it useful for security professionals. First, you can get in touch with experts in Information Security by connecting to security groups or inviting friends of friends. I also like the questions and answers section. You can ask questions or participate to answers on high level security topics and since the people that answers the questions gets a note, often high quality answers are provided on very interesting IT Security topics.