![]() |
| Microsoft has announced the launch of the free anti-malware Security Essentials. It uses the Dynamic Signature Service, a Microsoft technology that ensures users are protected by the most current virus definitions available without having to wait for the next scheduled download. In addition, it is designed to run quietly in the background and limits CPU and memory usage. Unfortunatly, it is a still in beta and available to customers in the United States, Israel, China and Brazil only. |
| Although I think that the age of the "Signature Based" security is over and the furure lays with concepts such as profiling (AppArmor), labeling (SELinux and Solaris Trusted Extensions) and Mandatory Access Control, that is a still welcomed edition to the information security domain. |
Tuesday, September 29, 2009
New Microsoft Security Essentials
Thursday, September 17, 2009
Security Development Lifecycle Tools from Microsoft
![]() |
| Microsoft has released two additional tools to supplement secure development life cycle (SDLC) tools portfolio which includes well known AntiXSS, FxCop and Cat.NET. |
| The BinScope Binary Analyzer is a Microsoft verification tool that analyzes binaries to verify that required compiler/linker flags are being set, strong-named assemblies are in use, and up-to-date build tools are in place. |
| MiniFuzz is a basic testing tool designed to help detect code flaws that may expose security vulnerabilities in file-handling code. This tool creates multiple random variations of file content and feeds it to the application to exercise the code in an attempt to expose unexpected application behaviors. |
| Both tools (and others) are available to download for free from the Microsoft Security Development Life cycle Tools Repository. |
Labels:
Analyse,
Code Review,
Flaw,
Fuzz,
Microsoft,
SDLC,
Source Code,
Tool
Tuesday, September 15, 2009
How we protect you... Yeah, how?
![]() |
| Seriously, I don't get it. It is 2009, the network firewalls have been here fore more that twenty years and people (information security professionals, no more no less!) still make those amateur assumptions that they will solve all their security problems. |
I've been reading HSBC's "Security guarantee" on their website (http://www.offshore.hsbc.com/1/2/international/internet-banking/how-we-protect-you) which states that they use the most advanced security systems and software to protect customer accounts including:
|
| Now that is secure, is not it? Well, no… Since application has access to the database, a skilled hacker would use encryption to bypass network firewalls (since firewall can not inspect the encrypted traffic) and user name/password fields could be used perform phishing, Cross Site Scripting (XSS) and SQL injections (diagram above). |
| In a year 2009, application security should be on the CISO agenda and network firewalls should be left to network administrators. Web applications should be protected by Web Application Firewalls (WAF), by constantly reviewing the source code to detect vulnerabilities and by training software architects and developers. |
Tuesday, September 8, 2009
Flash Cookies - Yammy!
| For some reason, everybody talks about flash cookies! But those are not much different to a traditional browser cookies we all know and love (to hate). The differences are that they are not controlled through a standard "privacy" setting of Internet browsers and they are less known (sadly, even to a Information Security specialists). |
| So where do you find those nasties and what to do about them? |
To find these flash cookies all you have to do is to look for .sol extension in the following directories:
|
There are number of alternatives to treat the problem:
|
| And there is legal twist to this story as well. Apparently, usage of Flash cookies is illegal in UK according to Guidance on the Privacy and Electronic Communications (EC Directive) Regulations 2003.: "Cookies or similar devices must not be used unless the subscriber or user of the relevant terminal equipment: * is provided with clear and comprehensive information about the purposes of the storage of, or access to, that information; and * is given the opportunity to refuse the storage of, or access to, that information." |
Thursday, September 3, 2009
AntiXSS v3.0
![]() |
| For years, (security aware) software developers were using OWASP ESAPI (Enterprise Security API) as a security framework to validate input/output to prevent Cross Site Scripting (XSS). Although it supports Java, Python, PHP and .NET among the others, only Java toolkit is mature enough to be used by the enterprises in production environment. |
| Now .NET users have Microsoft Anti-Cross Site Scripting Library to help protect applications from XSS attacks. In addition, enterprises may find Security Runtime Engine very useful since it has the ability to protect legacy applications from XSS attacks without having to change too much code. |
Monday, August 17, 2009
Malicious Facebook application
| . |
| Facebook had it share of a limelight (http://www.scmagazineuk.com/Warnings-made-over-malicious-Facebook-application/article/146596/) following bad publicity that hit Twitter previously. The way I see it, Facebook developers can try to develop a more secure application that will make attacks such as those more difficult, but unless people change their attitude towards their own private information nothing will stop hackers from obtaining it and using it for their own benefit. |
| As an organisation that owns the data, you can deploy smart perimeter security devices (Web Application Firewalls, Intrusion Prevention Systems, Network Access Control, Content Inspection, etc.), anti-malware software on your servers, perform rigorous patching and even use behaviour inspection databases. But, unless you address the core of the problem, which is lack of security awareness, and educate users (be those internal employees, software developers or the actual consumers of your services) those will have only a limited impact on the level of the security. |
| Now, the real questions is whose responsibility is it, anyway? As a Facebook user myself, I would expect Facebook to tell me right from wrong... |
Saturday, August 15, 2009
Whose Responsibility is it Anyway?
| Yesterday, SC Magazine published an article about PCI DSS compliance responsibility (http://www.scmagazineuk.com/Whose-responsibility-for-compliance-is-it-anyway/article/146476/) which I found very amusing. Why? Well, how come when you give something that is dear to you, you don't consider whom you give it to? |
| From a user prospective, if you don't think twice before you give away your private information, you have no one to blame but yourself. As a merchant or a service provider, you need to make sure that information that was given to you by the end user stays secure throughout data lifecycle and if you share it, it has to be someone who can provide at least the same level of security as you do. |
| PCI DSS requirement 12.8 is there to enforce that. Right now, merchant and/or service provider is not required to use only PCI DSS certified service providers but it is their responsibility to maintain a register of all third parties that have access to cardholder data, to have a proper contract in place (which includes acknowledgement by the third party of their responsibility for securing cardholder data) and review the associated risk regularly. |
Labels:
Compliance,
Data,
PCI DSS,
Responsibility,
Security
Wednesday, August 5, 2009
IBM has announced the acquisition of Ounce Labs
IBM has announced the acquisition of Ounce Labs, a provider of enterprise source code security testing (http://www.scmagazineuk.com/IBM-announces-acquisition-of-Ounce-Labs/article/140881/).
Earlier (I think last year), they acquired AppScan and now Ounce Lab; although both provide slightly different capabilities (source code security vs. web application vulnerability) it seems that IBM wants either to eliminate the competition or to have a single leading product in application security space. Would be interesting to see how it plays out...
Earlier (I think last year), they acquired AppScan and now Ounce Lab; although both provide slightly different capabilities (source code security vs. web application vulnerability) it seems that IBM wants either to eliminate the competition or to have a single leading product in application security space. Would be interesting to see how it plays out...
Labels:
Acquisition,
AppScan,
IBM,
Ounce Lab,
Review,
Security,
Source Code
Wednesday, November 21, 2007
Technological Means to Prevent Data Leakage
Before we dive into “Geeky Stuff”, let me tell you what this article is not about. This article will not detail data leakage prevention policies and procedures, nor will it detail specific vendor solutions.
This article will, however, provide a brief overview of the ways data can leak and details the technological means of protecting yourself from data leakage.
Why is Technology Important?
Let’s start with a question: What do the following individuals have in common - an underpaid developer in an off-shore software house who sold millions of code lines to competitors, a well paid employee who stored client files on his stolen laptop and an extremely well-paid manager in a governmental organization who decided to post two CDs on the Web containing data about millions of British citizens (including date of birth, addresses and back accounts)?
The aforementioned cases did not lack a data prevention policy – the organizations did have well-defined data leakage prevention policies and procedures – however they did lack technological means to enforce these policies.
Technology without Policy
Don’t get me wrong, policies are part of my bread and butter. Without well-defined and management approved policies there will be no legitimate reason to have technological tools in first place. Policies define which one of these digital streams is considered sensitive information and who is allowed (or not) to access and handle this information.
The Ways to Leak Data are Limitless
I will assume that our internal network and data storage are as secure as possible. In this case, there are only two ways to remove data from our stronghold:
How to Protect Yourself
There are many tools and solutions out there, but as I mentioned before this article will not go into detail on the solutions. There are a number of locations where we can detect the leakage and prevent it:
1. The Inner Circle
This is the best place to start. It is very tricky to prevent physical removal of information, but we can make it really hard for someone to try. So, why not limit access to the data in first place?
Many solutions exist to tackle this one. In my opinion, Role Based Access Control (RBAC) is the best approach to allow legitimate use of the sensitive information for business purposes while denying access to another.
2. Everything in Between
Here is where we need to think how to prevent data leakage. As I mentioned before, it is no simple task to prevent intentional or accidental leakage of sensitive data.
First, we need to make sure that all the hardcopies will be destroyed before leaving the premises. For that, we need to make sure that shredders are available and easily accessible.
Second, discontinue the use of writeable CD/DVD drives on your client systems. There is normally no reason for the average user to burn CD/DVDs. Furthermore, disable USB/Firewire storage and removable media. You might want to set up a number of stations where it will be possible to write CD/DVD, however limit access to managers or someone with higher privileges in order to filter the data leaving the organization.
3. The Outer Perimeter
Firewalls are our outer perimeter protectors. Usually, they are configured to block incoming traffic, however they allow most of the outgoing communication. This is also the best location to place a proxy server that will inspect all the outgoing traffic. Based on predefined rules (that is where policies come), a proxy can decide which data can leave the organizational network and what should stay in.
But even in organizations where a proxy is used to scrutinize outbound traffic, there are many additional services that are permitted through the firewall which are not inspected by the proxy. We can use NMAP (nmap –sT –p 0-65535) to map all the authorized ports through the firewall in order to get an idea of the existing potential areas for data leakage.
The most common way of bypassing a proxy inspection is to use an SSH port, which is usually open for administrative tasks. Users can easily tunnel anything they like over SSH. Also, as I mentioned before, just because the default port for SSH is 22, it doesn’t mean the SSH cannot run on any other port (such as over 80 or 443).
Additional methods include DNS or ICMP Tunneling. For example, tools such as OzymanDNS, NSTX and DNScat allow tunneling SSH traffic over DNS (and other protocols). In many cases, it is impossible to block a DNS protocol altogether, but for example, you can use internal a DNS server and allow DNS traffic only from that specific server through the firewall.
4. The Wide Wild West
In those rare cases when we do need our sensitive data to leave the protective walls of our organization, we need to make sure that the data is sufficiently protected. Believe me, using a ZIP file with ‘1234567890’ password (and that is a long password) is not considered protection at all. As an alternative, you could use PGP (of GnuPG) to encrypt your files with recipient(s) key(s) and then either write the data to CD/DVD or send it using electronic means, such as Email or Bittorent. Even in a case when CD/DVD will be lost, you can sleep quietly due to the fact that it is currently impossible to break an RSA1024 bit key (this is a minimum standard for today’s encryption).
Conclusion
Introducing a good set of organizational Data Leakage Prevention policies is not enough. On the other hand, technological solutions are meaningless without a good set of policies since you need to define what is allowed and what is not.
Technology is a necessary ‘tool’ to backup and enforce policies and in order to limit data leakage in an organization (it would be unwise to believe that it is possible to prevent data leakage altogether). A good combination of both technologies and policies is needed.
Published under Comsec Consulting UK
This article will, however, provide a brief overview of the ways data can leak and details the technological means of protecting yourself from data leakage.
Why is Technology Important?
Let’s start with a question: What do the following individuals have in common - an underpaid developer in an off-shore software house who sold millions of code lines to competitors, a well paid employee who stored client files on his stolen laptop and an extremely well-paid manager in a governmental organization who decided to post two CDs on the Web containing data about millions of British citizens (including date of birth, addresses and back accounts)?
The aforementioned cases did not lack a data prevention policy – the organizations did have well-defined data leakage prevention policies and procedures – however they did lack technological means to enforce these policies.
Technology without Policy
Don’t get me wrong, policies are part of my bread and butter. Without well-defined and management approved policies there will be no legitimate reason to have technological tools in first place. Policies define which one of these digital streams is considered sensitive information and who is allowed (or not) to access and handle this information.
The Ways to Leak Data are Limitless
I will assume that our internal network and data storage are as secure as possible. In this case, there are only two ways to remove data from our stronghold:
- Physical removal (such as hardcopy of softcopy on media such as CD/DVD, USB, etc.)
- Electronic means (dial up, Internet, FTP, SCP and every other existing way to transfer information).
How to Protect Yourself
There are many tools and solutions out there, but as I mentioned before this article will not go into detail on the solutions. There are a number of locations where we can detect the leakage and prevent it:
1. The Inner Circle
This is the best place to start. It is very tricky to prevent physical removal of information, but we can make it really hard for someone to try. So, why not limit access to the data in first place?
Many solutions exist to tackle this one. In my opinion, Role Based Access Control (RBAC) is the best approach to allow legitimate use of the sensitive information for business purposes while denying access to another.
2. Everything in Between
Here is where we need to think how to prevent data leakage. As I mentioned before, it is no simple task to prevent intentional or accidental leakage of sensitive data.
First, we need to make sure that all the hardcopies will be destroyed before leaving the premises. For that, we need to make sure that shredders are available and easily accessible.
Second, discontinue the use of writeable CD/DVD drives on your client systems. There is normally no reason for the average user to burn CD/DVDs. Furthermore, disable USB/Firewire storage and removable media. You might want to set up a number of stations where it will be possible to write CD/DVD, however limit access to managers or someone with higher privileges in order to filter the data leaving the organization.
3. The Outer Perimeter
Firewalls are our outer perimeter protectors. Usually, they are configured to block incoming traffic, however they allow most of the outgoing communication. This is also the best location to place a proxy server that will inspect all the outgoing traffic. Based on predefined rules (that is where policies come), a proxy can decide which data can leave the organizational network and what should stay in.
But even in organizations where a proxy is used to scrutinize outbound traffic, there are many additional services that are permitted through the firewall which are not inspected by the proxy. We can use NMAP (nmap –sT –p 0-65535
The most common way of bypassing a proxy inspection is to use an SSH port, which is usually open for administrative tasks. Users can easily tunnel anything they like over SSH. Also, as I mentioned before, just because the default port for SSH is 22, it doesn’t mean the SSH cannot run on any other port (such as over 80 or 443).
Additional methods include DNS or ICMP Tunneling. For example, tools such as OzymanDNS, NSTX and DNScat allow tunneling SSH traffic over DNS (and other protocols). In many cases, it is impossible to block a DNS protocol altogether, but for example, you can use internal a DNS server and allow DNS traffic only from that specific server through the firewall.
4. The Wide Wild West
In those rare cases when we do need our sensitive data to leave the protective walls of our organization, we need to make sure that the data is sufficiently protected. Believe me, using a ZIP file with ‘1234567890’ password (and that is a long password) is not considered protection at all. As an alternative, you could use PGP (of GnuPG) to encrypt your files with recipient(s) key(s) and then either write the data to CD/DVD or send it using electronic means, such as Email or Bittorent. Even in a case when CD/DVD will be lost, you can sleep quietly due to the fact that it is currently impossible to break an RSA1024 bit key (this is a minimum standard for today’s encryption).
Conclusion
Introducing a good set of organizational Data Leakage Prevention policies is not enough. On the other hand, technological solutions are meaningless without a good set of policies since you need to define what is allowed and what is not.
Technology is a necessary ‘tool’ to backup and enforce policies and in order to limit data leakage in an organization (it would be unwise to believe that it is possible to prevent data leakage altogether). A good combination of both technologies and policies is needed.
Wednesday, August 8, 2007
Security in a “Virtual” Reality
Today, every business tries to cut costs in order to be competitive in tomorrow’s market. Sometimes, this is done by outsourcing IT, HR or other non-core services. In other organizations, cost reduction is achieved by consolidating its IT environment by using Virtualization.
By creating multiple virtual machines which share resources such as CPU, memory, hard drive, network devices, etc. organizations are able to reduce the cost of management of server operation. This includes the hardware, maintenance and human resources needed to manage, operate and administer these servers on a daily basis.
Furthermore, in regard to Disaster Recovery Planning (DRP), virtualization can also enhance the security level by providing means to faster, more flexible, and more reliable disaster recovery at a lower cost. It also significantly reduces planned and unplanned downtimes.
This demand created many software vendors who would be happy to sell you their product. Examples include OpenVZ, Xen, VirtualBox, Virtual Iron, Virtual PC, VMware, QEMU, Adeos, Mac-on-Linux, Win4BSD, Win4Lin Pro, z/VM, and more.
However, failure to configure and harden your Virtual server might have very unpleasant results, especially when implemented without security considerations. In a number of cases we witnessed a hacker bringing down an entire virtual infrastructure because of a memory leak flaw on one of the servers. By exploiting this flaw, the hacker was able to consume all the available memory to a point where the entire system crashed.
The saying “Start Secure – Stay Secure” is a simple slogan used by Comsec to emphasize that security has to begin from the very first stages of design and integration, and should be integrated into every following step.
So, how do we secure a virtual environment?
Design a Secure Virtual Environment
Each solution has its own approach, which does not always suits the organizational needs. Some of these solutions completely separate each OS while others create separate “zones” with a shared kernel. Organizations need to determine security requirements that should correlate with the organizational security policy. A Security Architect should be involved in this stage in order to define parameters such as access control to server consol, design of virtual network architecture, design of virtual machines, communication protocols, etc.
Firewall
When implementing a virtual environment, some of the communication can relay on an internal, virtual network. For example, when a virtual web server communicates with a virtual database, the packets traverse through a virtual network only. A traditional firewall will not be able to filter this communication if needed.
There are a number of possible solutions. One of them is to use a firewall integrated into a virtual server application. The second option is to configure the virtual machines to route all the communication through an external firewall by connecting virtual machines to separate physical network cards. A third option is to use a “virtual” firewall which usually comes in the form of a virtual appliance. These appliances function as “traditional” firewall devices and can perform functions such as “Deep Packet Inspection”, session based rules, filtering, etc.
Hardening Virtual “Guest” Servers
In most cases we can assume that each virtual machine is fully isolated from another virtual machine running on the same server. These servers need to be hardened and tested periodically as their “physical” counterparts. Security vulnerabilities existing on one of the virtual machines could allow an attacker to skip from that machine to another in the network.
Hardening Virtual “Host” Server
“Host” servers are responsible for allocating memory and CPU to “Guest” servers, as well as providing access to storage and network devices. By receiving access to file systems on the “Host” server, an attacker will gain access to files stored on virtual machines. It is also possible to shut down the "Host" server which will result in DoS on each of the hosted "virtual" machines. These are only a few of the possible scenarios.
The “Host” server should be hardened and should undergo very strict access control. Only administrators and dedicated operators should have access to consol and virtual server management interfaces. The server should be updated with the latest security patches and it should be configured in a secure fashion.
(Security) Policies… Policies… Policies…
Every security decision should be backed up by an existing and approved policy. These policies should include:
Security Auditing
Security auditing should be performed on a periodic basis. Auditing should include:
Conclusions
Virtualization technology offers many operational and financial advantages. It even provides some security benefits. Nevertheless, this concept introduces several security weaknesses. The associated vulnerabilities include potential denial of service, data leakage and others.
With a proper and professional security approach towards the virtualization concept, one could achieve secure and reliable environment.
This approach should include proper secure design, secure configuration of the environment, secure maintenance, and proper periodical security audits.
Published under Comsec Consulting UK
By creating multiple virtual machines which share resources such as CPU, memory, hard drive, network devices, etc. organizations are able to reduce the cost of management of server operation. This includes the hardware, maintenance and human resources needed to manage, operate and administer these servers on a daily basis.
Furthermore, in regard to Disaster Recovery Planning (DRP), virtualization can also enhance the security level by providing means to faster, more flexible, and more reliable disaster recovery at a lower cost. It also significantly reduces planned and unplanned downtimes.
This demand created many software vendors who would be happy to sell you their product. Examples include OpenVZ, Xen, VirtualBox, Virtual Iron, Virtual PC, VMware, QEMU, Adeos, Mac-on-Linux, Win4BSD, Win4Lin Pro, z/VM, and more.
However, failure to configure and harden your Virtual server might have very unpleasant results, especially when implemented without security considerations. In a number of cases we witnessed a hacker bringing down an entire virtual infrastructure because of a memory leak flaw on one of the servers. By exploiting this flaw, the hacker was able to consume all the available memory to a point where the entire system crashed.
The saying “Start Secure – Stay Secure” is a simple slogan used by Comsec to emphasize that security has to begin from the very first stages of design and integration, and should be integrated into every following step.
So, how do we secure a virtual environment?
Design a Secure Virtual Environment
Each solution has its own approach, which does not always suits the organizational needs. Some of these solutions completely separate each OS while others create separate “zones” with a shared kernel. Organizations need to determine security requirements that should correlate with the organizational security policy. A Security Architect should be involved in this stage in order to define parameters such as access control to server consol, design of virtual network architecture, design of virtual machines, communication protocols, etc.
Firewall
When implementing a virtual environment, some of the communication can relay on an internal, virtual network. For example, when a virtual web server communicates with a virtual database, the packets traverse through a virtual network only. A traditional firewall will not be able to filter this communication if needed.
There are a number of possible solutions. One of them is to use a firewall integrated into a virtual server application. The second option is to configure the virtual machines to route all the communication through an external firewall by connecting virtual machines to separate physical network cards. A third option is to use a “virtual” firewall which usually comes in the form of a virtual appliance. These appliances function as “traditional” firewall devices and can perform functions such as “Deep Packet Inspection”, session based rules, filtering, etc.
Hardening Virtual “Guest” Servers
In most cases we can assume that each virtual machine is fully isolated from another virtual machine running on the same server. These servers need to be hardened and tested periodically as their “physical” counterparts. Security vulnerabilities existing on one of the virtual machines could allow an attacker to skip from that machine to another in the network.
Hardening Virtual “Host” Server
“Host” servers are responsible for allocating memory and CPU to “Guest” servers, as well as providing access to storage and network devices. By receiving access to file systems on the “Host” server, an attacker will gain access to files stored on virtual machines. It is also possible to shut down the "Host" server which will result in DoS on each of the hosted "virtual" machines. These are only a few of the possible scenarios.
The “Host” server should be hardened and should undergo very strict access control. Only administrators and dedicated operators should have access to consol and virtual server management interfaces. The server should be updated with the latest security patches and it should be configured in a secure fashion.
(Security) Policies… Policies… Policies…
Every security decision should be backed up by an existing and approved policy. These policies should include:
- Password Policy (expiration, password length, etc.)
- Authentication Policy (Token, LDAP, local / etc/passd, etc.)
- Access Control Policy
- Network Connectivity Policy (such as separation to VLANs, firewall rules, etc.)
Security Auditing
Security auditing should be performed on a periodic basis. Auditing should include:
- Security testing of “Guest” servers’ operating system and services
- Security testing of “Host” servers’ operating system
- Security testing of “Host” server virtualization application
- Relevant network equipment (switches, firewalls, routers, etc.)
Conclusions
Virtualization technology offers many operational and financial advantages. It even provides some security benefits. Nevertheless, this concept introduces several security weaknesses. The associated vulnerabilities include potential denial of service, data leakage and others.
With a proper and professional security approach towards the virtualization concept, one could achieve secure and reliable environment.
This approach should include proper secure design, secure configuration of the environment, secure maintenance, and proper periodical security audits.
Published under Comsec Consulting UK
Subscribe to:
Posts (Atom)

.gif)

