Given the nature of the web and the importance of data sensitivity of our client data we at sapnagroup try to adhere to the high levels of security for our systems and procedures. Highlighted below are the security features that we follow. Please note these are generic policies, and policies specific to a project/client may differ.
Table of Contents:
Our servers are configured with iptables firewall, which is a packet filtering firewall. Packet filters work by examining the IP packets. This allows us to determine how packets to and from the server get processed. We can make choices based on
source and destination
state of connection.
Only absolutely required services are available through the firewall, and checks for SYN Flood Protection, suspicious activity logging are also present. Special care has been taken to see that access to the database is made available only from the local system, and not from anywhere else on the Internet
Apache Mod Security
This is an open source web application firewall. ModSecurity acts as an intrusion detection and prevention engine for web applications (or a web application firewall). Operating as an Apache web server module or standalone, the purpose of ModSecurity is to increase web application security, protecting web applications from known and unknown attacks.
Regular security updates
Our server admin team is subscribed to various internet security advisories like www.frsirt.com, isc.sans.org etc and immediately patch/update the system whenever any security vulnerability is known.
All web activity (with details like how many people visited the site, which page the viewed the most, 404 document errors, which sites connect to our site i.e. referrers) are logged and are available to the customers under a password protected page for review.
At the same time all system logs are continuously analysed for problems/issues that might occur, specifically logs which indicate failed attempts of login (hack attempts) and email failures (problems in sending emails).
Our team is constantly in search and scripting of better method of monitoring and reporting, like services monitoring and auto restart of these in case of failures.
Administration is not a one time setup. It involves constant upgrade of services, tools, patches which help maintain better health conditions of servers.
This checks for services like FTPES, web, database etc on a regular basis (every 5 mins by default) and immediately reports any problems to the server admin team.
We do our own attempts to circumnavigate the system. Penetration testing is used during server and firewall set up and includes restricted access to SSH and FTPES. The server is subject to regular tests using security tools such as Openvas.
OpenVAS stands for Open Vulnerability Assessment System and is a network security scanner with associated tools like a graphical user front-end. The core component is a server with a set of network vulnerability tests (NVTs) to detect security problems in remote systems and applications. OpenVAS products are Free Software under GNU GPL and a fork of popular vulnerability scanner Nessus.
The frequency of these being used depends on the changes we make to the server. Every change to the server setup will then be subjected to these tests.
Apache2 mod security module of course ensures that any server code (PHP) follows the strict firewall rules predetermined by it.
Forced SSL3 protocol to ensure login details are encrypted over the internet
Captcha solution for creating logins which are valid for 90 seconds.
Passwords as SHA1 or MD5
Case sensitive user names and passwords
SSL protocol for all restricted areas to ensure all information exchanged is encrypted.
Only FTPES account opened which allows transfers of project related files.
PHPMyadmin access on a more complicated URL rather than /phpmyadmin. This is also over https (ssl) to ensure security.
Session stealing protection, and a variety of other steps (including predefined session hack) to ensure your session is safe.
Session ID information is forced to be sent via cookies rather then url-rewrite
Our scripts take into account all possible security related issues during the programming process. The scripts are tested for bugs wherein anybody with access to one area cannot get into another protected area. We also try to prevent spam hacking by effective use of captcha. Issues like SQL injection and session stealing are also taken into account during the coding process. Some things which we do as a standard coding practice
PHP Information non disclosure - By ensuring removal of all files which run commands like phpinfo() which give the settings information.
Administration panel on a more complicated URL rather than "/admin".
Implementation of CAPTCHA for admin login.
Our backup strategy is as follows
Weekly full backups
Daily incremental backups (backup only of files which are modified or new)
Daily MySQL backups
MySQL replication (the mirror server always has the latest database available at any point)
Backups are stored on both servers
All our backups are encrypted for security
Even though a good backup system is in place, for a smooth operation, a quick recovery is still essential. Also if the main server totally fails (hardware failure) there could be a considerable delay making the website to operate again. To provide a quick recovery in such cases we have a mirror server which is an almost exact copy of the main server (database is synced and files are maximum 1 day old). The switch to the mirror server in case of problems with the main server is a manual process.
Off site backups
Daily MySQL backups are encrypted and sent to an offsite server. They include only the crucial parts of the data, e.g. no web statistics. They are for worst case scenario that all our servers are not accessible anymore at all and the website needs to be set up on a completely new server.
Notification that the Website is down
The main issue is to be notified quickly if the website is down. There are server monitoring tools but even if the server is still running the website can be down, e.g. if the database crashed or if the server is overloaded. A remote server monitors the health of our live server very regularly. In case, the script feels that the live server is down, it will send an SMS to our server admin team. If there is a problem on your server we will notify you immediately about this via an sms (if you opt for that option) and give you the details including if possible how much time it will take to rectify.
Our server admin team is available for any emergencies and their mobile numbers are given to clients for such emergencies.
Bug in the website software
A bug in the website software can bring an entire website down e.g. a syntax error in PHP language, logic issue which takes a script in an endless loop. Proper test by programmers before they take the changes live, and after taking it live minimises this risk.
Users of the system (administrators etc) can by mistake delete entries using the CMS. This would cause important pages to go offline or errors appear on your Website. A proper backup solution will ensure a good recovery from this problem.
Hardware can fail, e.g. the hard-disk can go corrupt, the network card might stop working, etc. This will cause your entire website to fail.
DNS (Domain Name Server/Service/System) basically links your domain name e.g. yourdomain.com with your IP address (e.g. 192.168.0.1), so that it can forward all requests to this IP. If this fails, the internet would not know where to forward any users request for your domain.
Hack attack/malicious script attacks
Hack attacks happen everywhere. Every machine is prone to it. Either a user is trying to get into the system by trying various methods, or running a set of tools/script which automatically try different username password combinations, or bots automatically try different methods to get even a small access to run scripts which utilise all the bandwidth and processing power of the system causing a DOS (Denial of service).
Network problems with the ISP
There could be internal network problem issue with the ISP wherein the requests get forwarded correctly via the internet, but once they come to the ISP they fail to resolve.
Too much load on the server
Too many users using the Website or heavy scripts being called too many times can increase the server load which then would fail to service any new requests, making the website browsing experience unsatisfactory.
The operating system can crash. Although Debian (the OS on our server) has a reputation of being extremely stable, too many factors play a role in causing an OS to crash e.g. file corruption. Such a failure could bring the website down.
Internet network problems (e.g. overloaded internet as after the 7/7 terrorist attacks in London)
Internet problems cannot be ruled out. Although rare such problems do occur when too many users use the system. This could cause the website to be not reachable and hence appear offline.
The act of sending an e-mail to a user falsely claiming to be an established legitimate enterprise in an attempt to scam the user into surrendering private information that will be used for identity theft. If this is done on our server then the legitimate enterprise can contact the ISP (Hetzner) to request the website to be shutdown.
Phishing can occur only if they have access to our server e.g. ftp access, these are got using social engineering methods or via brute force attacks. We use fail2ban to prevent brute force.
The response time really depends on the task and the time of day. The time it takes to fix depends on the issue. We have outlined different scenarios in the document attached. The time mentioned below are guidelines, and the exact time to resolve a situation will be notified by the Supplier when any of the below listed steps are to be taken.
Remote server/service reset
Server reset basically means we restart the server/ service which is required when its memory contents go corrupt at times.
Remote hardware reset
Hardware reset is a forceful reset of the server. Useful when we cannot get access to the system to restart a service etc.
Switching to mirror server
We keep a mirrored server which at any point has all the files (mirrored daily) and the latest database at any point. We can switch over to this mirrored server if the main server has problems which could take a longer time to fix. Since this server is in a different building for safety purpose (fire in one building ensures data on the other is safe) we cannot dynamically switch IPs, but would rather have to update the A record and MX records which can take upto 48 hours to resolve.
Our ISP's data centre is available for any such requirement even out of office hours.
Fixing programming bugs
Programming bugs need to be reported to the concerned party / programmer. in case a script is causing an endless loop which causes a system failure we can terminate / disable such a script till the time the concerned programmer fixes it.
Backup restoration could be for a single file, group of files, the entire domain files, entire server files, and/or database.
Responding to a hacker attack
Need to identify the hacker script, understand what it does, which files it affects, understand how it entered the system.
Responding to DNS problems
If the DNS issue is in our hands (like a wrong MX entry etc) and the DNS setting for the domain is under our control we should be able to change this ourselves. If not we will report to the responsible party.
Responding to heavy load
Increase in load would mean we need to cater to this heavy demand by increasing system performance which could mean changing system configurations or updating the hardware like RAM.
Installing the website on a new server
Such setups take time. We have to configure the system, install the latest security updates, setup accounts FTPES, mail, system, setup backup procedures, run services.
Fixing ISPs network problems
We are not able to influence this but you can assume that our ISP will work with the very highest priority to get any network issues fixed as this affects all their clients.
ISP shuts down the server because of issues like our hacked server attacking other servers in the network, request from a 3rd legitimate party to shut down our server, etc
Our ISP would inform well in advance in case a request has been made by some external party to shut down our server/domain, and give us time to resolve our problem (so far it does not affect their other systems) and get back to the 3rd party directly to explain our situation.
PCs password protected at the BIOS level
All systems at our office are password protected by enabling BIOS password, which is different for every system.
Sensitive information download
Programmers do not download any sensitive data to PC.
Access to the live websites
Only senior developers have access to the live websites for development / maintenance purpose. They will only have access to websites there are working on.
All passwords are kept or distributed encrypted using Keepass / Axcrypt. All FTPES and database passwords generated are very randomised and substantially long so that someone can't easily remember them in memory. All server passwords are stored in an encrypted application and accessible to only 3 people in the organisation. Regular changing of admin passwords which are used by programmers.
Full control of all employee email accounts
Exchange of sensitive information
All sensitive information exchange within the company and across clients happens using encrypted software like Keepass / Axcrypt or using http://www.encryptedtransfer.com which has been developed by us.
Access to work stations
This is a risk which can arise in case a laptop is stolen / lost or somebody unauthorised tries to access data on a PC in the office. For this we put a bios password and a Windows password for all laptops / PCs used. We try to keep minimal sensitive data in unencrypted form on any desktop, laptop or office server. Most information is stored on our servers and even there, live database data or access is not stored unencrypted. For internal servers we have the same level of security as for our web servers (see above). All work stations have updated anti virus software and anti spyware applications installed. Only licensed software is used for development.
Information systems acquisition through recognised and trusted vendors
Development server and internet access
All development is done on 1-2 development servers which are located at the physical office premises. There are 2-3 ADSL lines for accessing internet. All these lines are routed through the development server which has a transparent proxy installed. All internet requests are therefore monitored. Also as a policy, we do not download sensitive data to our databases on the development server.Development server follows same security norm as the live server to prevent any hack attempts.
Vetting process for people applying for jobs
We make them go through 2 different written tests and an interview. We have a full fledged HR department which also does a reference check of all candidates and also scrutinises all their academic certificates for any fraud. Reference check done for all new recruits. Every employee signs a non disclosure agreement wherein he/she is expected to maintain the secrecy of all customer data.
When an employees quits the company, his email address is deleted so that he cannot access any of his old emails. We also change our access details on a regular basis so that a person cannot get into a system based on his/her old access.
SSH: Short for Secure Shell provides strong authentication and secure communications over insecure channels. It is a replacement for rlogin, rsh, rcp, and rdist. SSH protects a network from attacks such as IP spoofing, IP source routing, and DNS spoofing. An attacker who has managed to take over a network can only force ssh to disconnect. He or she cannot play back the traffic or hijack the connection when encryption is enabled. When using ssh's slogin (instead of rlogin) the entire login session, including transmission of password, is encrypted; therefore it is almost impossible for an outsider to collect passwords.
Incremental Backups: Backups taken after the main full backup is over. It contains only those entries (e.g. images, code files) which have added/changed after the full backup was taken.
SSL: Short for Secure Sockets Layer, a protocol developed by Netscape for transmitting private documents via the Internet. SSL uses a cryptographic system that uses two keys to encrypt data - a public key known to everyone and a private or secret key known only to the recipient of the message. This helps to protect sensitive data including passwords.
Captcha:A technique for differentiating humans from machines. A captcha method presents a problem that's relatively easy for humans to solve, but difficult or impossible for computers to solve at this time. One common captcha method presents users with an image containing some embedded text. Users must decipher the text and enter that along with the submitted login or user-account creation form.
Session stealing:Anyone who gets to know the current session id for any users (which itself is next to impossible if the server is setup well) will be able to access information. To prevent this session ids are cross checked with IP addresses (which are obtained at the time of login) to ensure security.
MD5: In cryptography, MD5 (Message-Digest algorithm 5) is a widely-used cryptographic hash function with a 128-bit hash value. As an Internet standard (RFC 1321), MD5 has been employed in a wide variety of security applications.
SHA1: The US Secure Hash Algorithm takes a message of less than 264 bits in length and produces a 160-bit message digest designed so that it is computationally very expensive to find a text string that matches a given hash
HTTPS: (Hypertext Transport Protocol Secure) the protocol for accessing a secure Web server. Using HTTPS in the URL instead of HTTP directs the message to a secure port number rather than the default Web port number of 80. The session is then managed by a security protocol such as SSL3.
FTPES: FTPES (commonly referred to as FTP/SSL) is a name used to encompass the way in which FTP software can perform secure file transfers. Each way involves the use of a SSL/TLS layer below the standard FTP protocol to encrypt the control and/or data channels.
DoS attacks: An attack to make the computer resources unavailable to genuine users. A common attack would be to make high saturated requests to the computer so that other legitimate requests suffer (denied or rendered slow) as the computer is busy responding to the attackers request.
Brute force attack: An attack in which a large number of combinations are tried in an attempt to make one of them successful. E.g. for a username password box, an attacker might keep on trying different combination hoping one of them will work. Automated attempts at brute force help reduce the time duration required.