For medium to large data volume environments, it is advisable to physically separate application and database servers.
Web applications are an easy target for script kiddies and black hats alike. Web applications also have some form of access to the organization’s data. It is imperative that protection mechanisms be put in place against attempts to break into web applications.
As part of the business continuity or disaster recovery, it is imperative for every organization to maintain a copy of its electronic data at an offsite location. Offsite backups can be maintained manually or through automatic means. When maintained manually, the backups are taken physically on media like tapes, magnetic discs etc at the onsite location and then transported to the offsite storage location. In an automatic offsite backup, there is no manual intervention involved and therefore is less error prone and can be done at more frequent intervals. Couple of automatic offsite backup solutions are listed below. Continue reading “Automatic offsite backup techniques”
Researchers Steven J Murdoch and Ross Anderson criticise the current method of Credit-Card verification Scheme. They found that the current mechanism used by “Verified by Visa” from Visa and “MasterCard SecureCode” from Master Card are flawed. Banks worldwide are starting to authenticate online card transactions using the “3-D Secure” protocol.
They observe that:
The mechanism used to display the 3DS form is embedded within an iframe or pop-up with no address bar, so there is no indication of where the form has come from. This goes against banks advice to their customers to avoid phishing sites. By only entering bank passwords into sites they can identify as the bank’s own site.
The researchers also criticise the initial password entry process which occurs the first time a card holder uses a 3DS enabled card to shop online. The user is asked to enter a new password as part of the process of making the purchase, which the researchers feel is a bad time to ask for the password as the user is probably more interested in shopping and more likely to choose a weak password.
The 3DS specification only covers the communication between the merchant, issuer, acquirer and payment scheme, not how customer verification is performed. Liability of fraud is transferred to the customers.
What should be done technically?
They believe that single sign-on is the wrong model. What’s needed is transaction authentication. The system should ask the customer “You’re about to pay $X to merchant Y. If this is OK, enter the auth code”. This could be added to 3DS using SMS messaging, or systems like CAP (Chip Authentication Program) as a stopgap.
In the long term we need to move to a trustworthy payment device. This is not rocket science; rather than spending $10 per customer to issue CAP calculators, banks should spend $20 to issue a similar device but with a USB interface and a trustworthy display.
What must be done to make it happen?
Incentives are the key. Visa and MasterCard have managed to get 3DS deployed by arranging so that merchants and banks benefit (at least in the short term) while consumers lose out. What’s needed now is for regulators to intervene on behalf of the consumer. The EU already has the Electronic Signature Directive, which contemplates shifting the liability for electronic transactions to bank customers if they are equipped with a secure electronic signature creation device. The missing word is `only’. If the liability shift is permitted only once the technology actually empowers the customer to decide what transactions she will authorise, then the incentives will line up and finally we might start to move toward a sustainable infrastructure for cardholder-not-present payments.
Reference : http://www.cl.cam.ac.uk/~rja14/Papers/fc10vbvsecurecode.pdf
This blog will focus on the approach to be taken to audit Access Control in a Microsoft SQL Server environment.
1. Control: Processes should exist to ensure that access granted to both general and privileged users is appropriate and is removed when no longer needed.
1.1 Review processes for granting, updating, and terminating user access.
1.2 Obtain a list or file containing information on current database users and administrators, and their roles.
1.3 Obtain a list or file containing information on current local Windows Server groups and the members of each group.
1.4 If privileges to access objects or statements are assigned directly to users –
- Obtain a list or file containing information on users with individual privileges and the related objects to which they have access.
- Evaluate the access based upon job descriptions and the access granted.
- Examine related access requests for reasonableness and proper authorization.
- Discuss possible excessive access rights with the DBAs, Information Security and the Business Owners as dictated by the circumstances.
1.5 Review privileges assigned to users and roles. Discuss with the DBA and data owner any privileges directly assigned to users rather than to roles.
1.6 Select a sample of user access requests and verify that access is approved by the appropriate data owners.
1.7 Review the roles and privileges assigned to a sample of users. Ensure that the users’ access is commensurate with their job responsibilities.
1.8 Obtain a list or file of terminated employees from HR. Compare the terminated employee list or file to the list or a table of database users to ensure that accounts are terminated in a timely manner.
1.9 Review the assignment of fixed server roles (sysadmin, serveradmin, etc.) to provide reasonable assurance that these roles are used only in support of DBA activity.
2.0 Review any roles and/or user accounts that are assigned CREATE, ALTER or DROP privileges. Discuss the business requirements for these types of highly privileged access with the DBA and other affected manager(s).
2.1 Review accounts that are assigned highly-privileged roles such as sysadmin. Discuss the requirement for this type of access with the DBA and Information Security Officer. Assess each of these accounts for possible segregation of duties issues.
2.2 Verify that the GUEST user is removed from or disabled in all databases. Discuss any exceptions with the DBA.
2.3 If the public or GUEST USERIDs remain in the database and are enabled, verify that these ids are not granted access to any objects.
2.4 Verify that the database owner (dbo) owns all user-created database schemas.
2.5 Review the security over access to OS executables (cmd.exe, explorer.exe, etc) on the SQL Server and the SQL Server install directories. Ensure that users’ unique or group permissions do not grant full control.
2.6 Review assignment of the GRANT object permission to verify that it is not assigned to users or roles. Discuss any of these existing privileges with the DBA.
The above list is to just serve as a reference and exceptions can be made based on need.
Reference : This list is adapted from ISACA’s SQL Server Assurance book.
HTML5 is the latest version of HTML, currently under development. HTML5 has some really amazing features that we will explore in this article. The first draft of HTML5 was released in 2008 and major browsers are beginning to incorporate HTML5 features. The final version of the standard is not yet released (and not expected to be released any time soon).