CypherSec.ValidationLibrary
Features:
- Robust Validation. 50+ Different types of Data (Email,Nationality,Name,PhoneNumber (US,UK),PostCode, Major Credit Cards etc)
- Fully customisable. Hot-and-live, you can change/add/remove validation rules as you wish, all you need is NotePad and a bit of understanding of Regular Expressions.
- Easy to use and setup. Using this library is ridiculously easy.
- MultiPlatform. CypherSec.InputValidation can run on any GNU/Linux, UNIX, Mac OSX and Windows Operative System as long as MONO is supported.
- Stable. 60+ Unit Tests
Data Classification
When defining any data classification system, the definitions of each class must be based upon objective properties that are easily recognisable. The definition of these classes will reflect the criteria that data must meet in order to be classified to that level. In addition, the definition should include, in general terms, examples of the roles that should have access to data in that class. Clear criteria should be provided that will allow the security analyst to unambiguously recognise the class that should be assigned to an element of data. It may be tempting to suggest methods of mitigation risk with the class descriptions, such as "all data in this class must be encrypted", but this should be reserved for the development of data handling policies which occurs immediately following the creation and assignment of data classes.
A key aspect of the success of a data classification system, regardless of its purpose, is simplicity. The creation of too many classes will result in a system that is difficult to manage and enforce.
A good set of classes might be.
Low Sensitivity (Public)
Information that is publicly available through other civil sources, or that has been specifically designated as public information by regulation or corporate security.
Medium Sensitivity (Internal Disclosure Only)
Information that would cause minor damage to the organisation or subject if disclosed externally from the organisation. The damage referenced in this description includes exposure to litigation, compromise to security of assets, reputation of organisation and its associates, elimination of competitive advantage, and violation of regulation, industry standard or corporate policy. This damage potential will be determined in conjunction with corporate legal counsel. If the class is undeterminable, consider this class as default.
High Sensitivity (Restricted to Specific Personal)
Information that would cause major damage to the organisation or subject if disclosed externally from the organisation. The damage referenced in this description includes exposure to litigation, compromise to security of assets, reputation of organisation and its associates, elimination of competitive advantage, and violation of regulation, industry standards or corporate policy. This damage potential will be determined in conjunction with corporate legal counsel. This class includes information that is designed explicitly as sensitive or identifiable through regulation, industry standard or corporate policy.
The fact that "Medium" is designed as class as the default, rather than "Low" or "High", instructs the security analyst that the disclosure of all data should be restricted to internal personnel unless otherwise justified
The definitions of who is permitted to view each level of sensitivity data are intentionally broad at this stage.
Types of Sensitive Data
This post provide some specific examples of data that is generally considered sensitive by laws, regulations or industry standards
Government Assigned Identification
Throughout the world, individuals and business are provided with various identification numbers, by their respective governments. This data is important to governments for validation of citizenship, work status, taxation, claiming of benefits, general identification and licensing. The following are few examples of identification numbers that are assigned by governments around the world.
- Driver's License Number
- Passport Data
- Social Security Numbers (USA specific)
- Employer Identification Number (USA specific)
- Individual Taxpayer Identification Number (USA specific)
- Preparer Taxpayer Identification Number (USA specific)
- Value added Tax identification Number (EU specific)
- Unique Tax Payer Reference (UK specific)
- National Insurance Number (UK specific)
- Company Tax Reference (UK specific)
- General Index Reference Number (India specific)
- Permanent Account Number (India specific)
- Tax File Number (India specific)
All of these pieces of data are to be considered sensitive. When a given identification number is used widely, beyond its original purpose, the potential damage from unauthorised disclosure increases.
For example, consider the Social Security Number, first introduced in the United States by President Franklin Roosevelt in 1935. Its initial intent was to identify a tax payer who was paying the Social Security Tax. Attached to this tax are various benefits such as retirement and disability benefits. However, over the decades this number became much more widely used as a way for organisations, business, hospitals and educational institutions to uniquely identify a US Citizen.
Due to this extended usage, the unauthorised disclosure of the Social Security Number opens a Pandora's Box of possibilities for fraudsters. The Social Security Number is associated with credit reports, financial records, medical history, tax records, passports, birth certificates, public records, voter registration, professional licenses and many other items that are used to validate identity.
Laws have been enacted over the years as the Federal level, such as the United States' Gramm-Leach-Bliley Act, and at the state level, such as Indiana Code 9.24.6.2, in an effort to curtail use of the Social Security Number beyond its intended purpose. However, there remain many legacy systems that utilise the SSN to uniquely identify a customer's record.
So the recommendations are
- Keep an eye out for the use of any government assigned identification as the primary key, or as a unique identifier, for an individual or business.
- Strongly discourage the use of sensitive data for this purpose. It is far preferable to use a system-generated value that does not have meaning beyond the database, such as using an auto-numbering column or a GUID to define the primary key for the customer.
Understanding Sensitive Data
Data is a form of currency. As members of society, we provide information about ourselves to gain access to services and goods that we desire. We collect information about others in order to market our services and obtain verification of identity. As Security professionals it is our lifeblood. In order to effectively protect our customer sensitive data, it is critical that we understand the characteristics that define that data as being sensitive.
What Makes Data Sensitive?
Sensitive data can be defined simply as information that the holder does not wish to share publicly. A wild array of information could fall into this category, depending upon the motivation of the holder at any given time.
There are laws, regulations and industry standards that provide a solid framework for defining sensitive data. In UK we have the Data Protection act of 1998 for example.
The three most common terms used to describe sensitive data are
- Personal Data
- Identifiable Data
- Sensitive Data
Personal Data
The term "personal data" can is very broad in scope. It can apply to any data that pertains to an individual, and does not necessarily reflect its level of sensitivity.
According to the UK Data Protection act of 1998, personal data is defined as follows:
... data which relates to a living indivudual who can be idenfied a) from those data, or b) from those data and other information which is the possession of, or is likely to come in the possession of, the data controller
Identifiable Data
Identifiable data is more a specific term that personal data. It applies specifically to information that uniquely defines an individual. In a memorandum to the Executive Department and Agencies of the United States Federal Government, from the White House, the definition of identification data is
... Information which can be used to distinguish or trace an indivudual's identity, such as their name, social security number, biometric records, etc. Alone, or when combined with other personal or identififying information which is linked or linkable to a specific individual such as date and place of birth, mother's maiden name, etc
Data is defined as Identifiable requires an elevated effort in regards to its protection, and the prevention of improper disclosure.
Sensitive Data
Sensitive Data is a term that includes identifiable data, but also extend to information that may be considered private, or to have social and economic consequences if improperly disclosed. It is also information that could cause harm to an organisation if it is improperly disclosed. This type of data includes political opinions, religious beliefs, mental or physical condition, criminal records, financial status, intellectual property, organizationational membership, codes and passwords that grant access to accounts, and information of national security.
According to the UK Data Protection Act of 1998, Sensitive Data is defined as
..personal data consiting of information as to a) the racial or ethnic origin of the data subject, b) his political opinions, c) his religious beliefs or other beliefs of a similar nature, d) whether he is a member of a trade union..., e) his physical or mental health or condition, f) his sexual life, g) the commission or alleged commission by him of any offence, or h) any proceedings for any offence committed or alleged to have been commited by him, the disposal of such proceedings or the sentence of any court in such proceedings
In the definition provided by the Data Protection Act, it is specific to information of any individual; but data spans beyond the scope of the individual and includes business, organisations and nations. Data that is considered sensitive will always require additional effort to protect it and prevent unauthorised disclosure.
Further Readings
- United Kingdom's Data Protection Act 1998
- Protecting SQL Server Data
How to Secure a SQL Server Database
This is a relatively small post on how to secure a SQL Server Instance. It contains the most important configuration settings you should look at when deploying a SQL Server as Back-end for a secure system. Most of these configuration settings are easily applicable, and do require limited knowledge of Server Administration. However, before implementing any of these changes to production it is highly recommended you check with your DBA group first.
- Application Server should communicate with the database using leased line.
- If a leased line is not applicable, severe firewall rules should be in place in order to allow incoming connections only from trusted sources. (Application Server).
- Restrict sysadmins-only access to dangerous stored procedures and extended stored procedures. There are quite few of them and this could take some time. It's good practice to test the changes on a development machine so you don't break functionality.
- Disable port TCP 1433 and UDP 1434 for all un-trusted clients. These ports are used to initiate remote connections.
- Use Windows Only authentication mode. Doing so will simplify administration by relying on the OS Security and saving yourself from maintaing two security models. This also keeps passwords out of connection strings.
- Enable logging for all user login events (using xp_instance_regwrite).
- Disable SQL Mail capability unless absolutely necessary.
- Remove the Guest User to keep unauthorized users out.
- Use a low-privilege user account for SQL Server service rather than LocalSystem or Administrator.
- Secure the "sa" account with a strong password. This assume you are using the SQL Server and Windows Security mode. If possible, use the Windows Only and don't worry about people about brute-forcing your "sa" accounts. Of course, even so you'll want to set a strong password in case someone changes modes on you.
OWASP Code Crawler 2.5 Released
OWASP Code Crawler is a .NET Windows Forms application built using Microsoft .NET C#, XML, Linq and few third parties open source components. Its development started in fall 2007 as a very simple prototype from a mail conversation between me (Alessio Marziali) and Eoin Keary (Code Review Project Leader and Board Member). Eoin spotted the hidden power of this tool and asked me if I could be interested in making it open source. Thrilled by the idea of joining OWASP, few months later Code Crawler became an official OWASP Project.
Over the years Code Crawler has substantially grown, mainly with the help of other volunteers around the world, and today I am very pleased to announce we have reached version 2.5. I personally want to thanks Tripurai Rai, Sasikumar Ganesan and Paulo Coimbra for helping me make this happen. In this release we have been focusing mainly on the UI of the application and also improved our database while introducing utilities like STRIDE, DREAD Calculator and ASP.NET ViewState Decoder. For a detailed list of features you can refer to the changelog attached at the end of this post.
License
OWASP Code Crawler 2.5 is a Creative Commons Attribution Share Alike 3.0 open source application which means you are free to copy, distribute, transmit and remix this code as you like. In this case, you must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work). If you alter, transform, or build upon this work, you may distribute the resulting work only under the same, similar or a compatible license.
Download
OWASP Code Crawler 2.5 can be downloaded from http://codecrawler.codeplex.com. Please be advised that in order to run Code Crawler requires Microsoft .NET Framework 3.5. You may download it from here (link to Microsoft download website).
Changelog
- Code Crawler Editor
- Find (CTRL+F)
- Mark Findings
- Select All (CTRL+A)
- Copy as RTF (sweet)
- CodeFolding
- SyntaxHighlight
- BracketMatching
- Unlimited Undo/Redo buffer
- Bookmarks
- Go to line (CTRL+G)
- Replace
- Breakpoints
- Single Scan Form
- New User Interface
- STRIDE Classification
- Direct links to MSDN and Google
- Shortcuts to Notepad and Calc
- Threats Count
- Printing
- RTF Report
- Visual Studio .NET (for VS 2005 - 2008)
- Supports ONLY C# Project files (*.csjpro)
- Bigger fonts
- Mainform
- New User Interface
- Links to OWASP content
- WASC Threat Classification 2.0
- Sun Java Guidelines
- Removed OWASP Browser
- Removed Network Scan
- Removed Reporting Frame
- Database
- 286 Keywords
- Multi STRIDE Schema
- Refactoring
- Utilities
- ASP.NET ViewState Decoder
- DREAD Calculator
OWASP Code Crawler 2.5 – Screenshots
It has been a while since I have posted something about Code Crawler, the project I am developing since fall 2007. Our development team, which is now composed by three developers, is in the process of making the magic happen again.
What follows is a list of screenshots of Code Crawler 2.5. Code Crawler is more or less a new project today. We have taken the good and removed the bad. So far we have completed STRIDE automatic classification, DREAD, Improved performances, Enchanted our database in terms of quality and quantity and most of all we said good bye to our previous UI.
Single File Scan new User Interface.
Visual Studio .NET (2005/2008) Integration is now fully working.
Code Crawler can now scan hundreds of files at the same time without leaving nothing behind. In this example Code Crawler has finished scanning a very busy Visual Studio Solution and an external file using single file mode. The user can switch easily between the result at any time.
Dread Calculator is an easy to use tool integrated within Code Crawler which makes Risk Analysis easy.
Code Crawler provides direct links to all OWASP major contents such as Guides and tools.
The single source code file form provides easy accessible options such as:
- Archive (for reporting purposes and further investigations)
- Print Source Code
- Notepad
- Calc
- MSN
- Threats Count.
Download links, next week, hopefully.
Microsoft releases Cross Site Scripting Security reference.
Cross-site scripting attacks are on the rise because they are easy for attackers to craft and execute. In addition, they allow attackers to gather the most valuable content (user data) rapidly and in a manner that can easily go unnoticed by the user and often the Web site or application itself. As XSS attacks continue, it is imperative that development organizations prepare themselves with the solutions needed to rapidly address the problems as they occur. It is equally important that long-term solutions including security policies/requirements are in place to design, implement, verify, and release code that proactively protects your customers from XSS attacks.
Microsoft has released another document as part of their SDLC document library. This time is a 21 page document titled “Quick Security Reference : Cross Site Scripting”. The scope of this document is to increase awareness of XSS Vulnerabilities to each persona involved in software development. In particular Microsoft identifies four different roles: Business decision maker, architect, developer and tester.
Quick Security Reference Cross Site Scripting Reference also includes results of a basic survey of software companies that have established practices for fixing vulnerabilities that lead to attacks approximate that the costs associated with remediating a Web site that has encountered XSS like attack is around 40-man-hours per incident. That cost combined with the cost of hiring or training engineer to address the problem (~100$/hour) and the average number of seven XSS (or similar) exploitable vulnerabilities per Web site brings the total estimated cost to $28,000 to fix each problem reactively.
Figure 1. “12 Web application vulnerabilities between January 2006 and June 2007” shows XSS at the top of the ladder leaving no doubt that XSS is definitely one of the most exploited vulnerabilities in today applications.
Each persona is then introduced to different topics related to XSS, strictly related to their role and responsibilities. An architect will be more involved in Input Validation Rules, Output encoding strategies, Future Design Considerations rather then Identifying Untrusted Input and Writing Secure Code just to mention few. Useful insights on how to identify and classify an XSS type vulnerability (Reflected, Stored, Local) and software development best practices are also part of the document.
In conclusion; Software developers may find this document surprisingly useful as it covers almost everything they need to know in order to prevent, discover, mitigate and fix XSS vulnerabilities.
32 millions accounts stolen? An inconvenient truth
A site for social networking developers has been hit with a major SQL Injection attack that exposed more than 30 million user names and passwords RockYou, a site that delivers widgets for social networking developers for MySpace, Facebook and other. The bug has been fixed but not before the hacker it.
In fact, the hacker that goes by the alias “igigi” has published on the 15th of December on his blog the Rockyou database structure along with samples of the stolen data. The hacker claims he has downloaded over 32,603,388 (32 millions) user accounts.
Rockyou is currently making users aware of what happened and what they are doing in order to reduce the harm.
“We are investigating the data breach, reviewing our security protocols, and implementing new practices to prevent this from happening again. For example, we are taking the following steps:
1. We are encrypting all passwords;
2. We are upgrading the legacy platform with the same infrastructure and industry standard security protocols we employ on our partner applications platforms;
3. We are reviewing our current data security features and ensuring that they meet industry standards and best practices; and
4. We are cooperating with Federal authorities to investigate the illegal breach of our database.We are sorry for the inconvenience this illegal intrusion onto the RockYou system has caused our users. We will continue to advise our users of any information that would help them.
What we can learn from this accident is quite obvious, SQL Injection is still one of the most popular threats, and of course, storing password as simple plaintext is definitely one of the biggest mistakes you can do while architecting a web application. This is why less than a month ago I was writing here on cyphersec.com a series of best practices aimed at increasing web application security. I’m sure I’ll add the Rockyou accident to the list of real world examples that proves why having plaintext passwords is a bad idea.
Rule 14# - Never compare passwords, compare the hash. Do not use MD5 which could be hacked using Rainbow tables, use RIPEMD160 instead.
Anyway, the worst part of the story is not the reputation of Rockyou which, obviously, has been hit hard - the problem is people still considering the side effects of non implementing application security as an inconvenient.
DarkReading – Social Networking Developer Site Database Hacked In Sql Injection Attack
Owasp Foundation – SQL Injection Prevention Cheat Sheet
cyphersec.com – Security Best Practices: ASP.NET Applications
cyphersec.com – Toyo Tires, How to steal a database (Italian Language)
Microsoft security considerations for clients and cloud applications
Microsoft is about to release its new Cloud computing product named Windows Azure by January 2010. Azure will provide a new Cloud Computing option to software vendors and application developers.
With that said, Microsoft has released on the 13th of November a six paged document “Security Considerations for Client and Cloud Applications” via their Secure Development Lifecycle website. Surprisingly, the document doesn’t actually includes any advice for application developers nor for IT Managers considering moving their applications on the cloud.
It’s more just a “Look. Here how we do cloud computing at Microsoft and, as you can see we do actually care about security. So pick us up” document.
The only interesting part of the document which is worth mentioning is an overview of what the Operational Services Security and Compliance team within Microsoft does. OSSC team works across the operation, product, and service delivery teams and with internal and external auditors to ensure compliance with the relevant standards and regulatory obligations.
The following list presents an overview of some of the audits and assessments that the Microsoft cloud environment must undergo on a regular basis:
- Payment Card Industry Data Security Standard (PCI-DSS). This standard requires an annual review and validation of the security controls related to credit card transactions.
- Media Ratings Council. This relates to the integrity of advertising system data generation and processing.
- Sarbanes-Oxley (SOX). This legislation requires that selected systems are audited annually to validate compliance with key processes related to financial reporting integrity.
- Health Insurance Portability and Accountability Act (HIPAA). This act specifies privacy, security, and disaster recovery guidelines for the electronic storage of health records.
- Internal audit and privacy assessments. Assessments occur throughout a given year.
After analyzing all of these requirements, Microsoft determined that many of the audits and assessments required an evaluation of the same operational controls and processes. Recognizing the significant opportunity to eliminate redundant efforts, streamline processes, and proactively manage compliance expectations in a more comprehensive manner, the OSSC team developed a comprehensive compliance framework. This framework and associated processes follow the five-step methodology represented in the following illustration.
-
Identify and integrate requirements. Define the scope and applicable controls. Standard operating procedures (SOPs) and process documents are gathered and reviewed.
-
Assess and remediate gaps. Identify and remediate gaps in process or technology controls.
-
Test effectiveness and assess risk. Measure and report on the effectiveness of controls.
-
Attain certifications and attestations. Engage with third-party certification authorities and auditors.
-
Improve and optimize. Assess and document the root cause of any noncompliance, and then track the remediation process. This phase also involves continuing to optimize controls across security domains to generate efficiencies in passing future audit and certification reviews.
Different Applications different level of security required
The security required will vary, depending on the type of system. For example, a government system dealing with millions of social security numbers will have much stronger requirements than a standard business application. Microsoft classifies systems as low, moderate, or high business impact to help determine security requirements and the strength of security features that they must provide. The categories take into account the relative potential for financial and reputational damage if the asset was involved in a security incident. For example, data assets falling into the moderate impact category are subject to encryption requirements when they reside on removable media or when they are involved in external network transfers. Data in the high impact category, in addition to moderate impact requirements, is subject to encryption requirements for storage and for internal system and network transfers.
For all cloud services that Microsoft offers, the documentation provided to users will always state what is protected and how it is protected. For example, users who choose to host their applications “in the cloud” may want to have their applications and processing protected from those of other users. For these users, Microsoft is committed to providing this level of protection. Additional security feature and protection requirements will vary from user to user, and from application to application, depending on data sensitivity and on applicable laws and regulations. Microsoft will be transparent about the strength and applicability of the security protections that its cloud services offer so that users will know what security features and processes are available, and will be able to determine how Microsoft will protect their data and processing. The information provided will enable users to evaluate the suitability of Microsoft’s cloud platform for their security requirements and to make informed decisions about their use of cloud services.
