Incident response plans (IPR) provide instructions on how you should respond to potential hack scenarios, including data breaches, DoS (Denial of Service)/DDoS (Distributed Denial of Service), firewall breaches, virus or malware outbreaks or insider threats.
According to the SANS Institute, there are six key phases of an incident response plan:
- Preparation: Preparing users and IT staff to handle potential incidents should they should arise
- Identification: Determining whether an event is indeed a security incident
- Containment: Limiting the damage of the incident and isolating affected systems to prevent further damage
- Eradication: Finding the root cause of the incident, removing affected systems from the production environment
- Recovery: Permitting affected systems back into the production environment, ensuring no threat remains
- Lessons learned: Completing incident documentation, performing analysis to ultimately learn from incident and potentially improve future response efforts
A security audit/ VAPT (Vulnerability Assessment and Penetration Testing) to find security bugs & loopholes in the website. Such an assessment is essential to patch "show stopper"vulnerabilities before the big sale day. A typical security audit helps you identify the following security issues:
- SQL Injection
- Business Logic errors
- Cross-site Scripting (XSS)
- Amount Manipulation during checkout
- Denial of Service
- Broken Access Control
- Weak authentication/authorization
- Unrestricted file uploads leading to 'shelling' of server
- Server takeover possibilities
- Open Redirection vulnerabilities
- Ad-ware, Malware & Backdoors
- Injection attacks like XSS, LFI, RFI
It is a good idea to have more bandwidth than you would plausibly need since over-provisioning provides extra time to identify and deal with the attack. It ensures that the server is able to accommodate unprecedented spikes in traffic without causing outages for customers.
You should create a vulnerability disclosure page so that hackers can responsibly disclose any security loopholes they may find on your portal. This way you can ensure that the details of the vulnerability are not disclosed to the public and your website remains secure.
Firewalls tend to be a great defense against hack attempts, automated tools and bots. They'll block out malicious requests irrespective of the vulnerability being there in your website or not. It helps you to keep the bad guys away from your infrastructure.
Configure your web server to use HTTPS/SSL (Secured Socket Layer). It will encrypt the traffic from the visitor's web browser to your server. It is used to ensure data confidentiality & data integrity through encryption and hashing.
Redirect traffic from the HTTP version of the website to the HTTPS version for added security. Set the Secure flag for all session cookies, use SSL certificates with Extended Validation.
Applications should enforce password complexity rules to discourage easy to guess passwords. The password change mechanism should require a minimum level of complexity as described below:
- Password must meet at least 3 out of the following 4 complexity rules
- at least 1 uppercase character (A-Z)
- at least 1 lowercase character (a-z)
- at least 1 digit (0-9)
- at least 1 special character (punctuation) — do not forget to treat space as special characters too
- at least 10 characters
- at most 128 characters
- not more than 2 identical characters in a row (e.g., 111 not allowed)
You can use How Secure is my password? to check the strength of your passwords
Passwords must be stored in system using "Hashing". Storing plain passwords in your database is unethical, wrong and extremely dangerous. Therefore, passwords must be hashed before storing them. Also the hashing algorithm used must be cryptographically secure and must produce a long random string, otherwise they can be cracked. Some secure hashing functions:
- Argon2 is the winner of the password hashing competition and should be considered as your first choice for new applications;
- PBKDF2 when FIPS certification or enterprise support on many platforms is required;
- scrypt where resisting any/all hardware accelerated attacks is necessary but support isn’t.
- bcrypt where PBKDF2 or scrypt support is not available.
You should restrict open ports, and ports exposed on the Internet for only essential services. Perform regular audits to detect new ports in the listening state, which could indicate unauthorized access and a security compromise. Often ports like FTP, SSH etc. are left open on the server allowing hackers to brute-force or exploit vulnerabilities to gain access to the server.
If it is necessary to use such services on a production server, put in place IP restrictions such that only whitelisted IP addresses/ranges can access the server.
It's always a good idea to reduce the attack surface area. Remove any code form the server that you are not using. Hackers try to find security issues in unused & outdated software to gain access to the server and databases.
You can make a list of all sub-domains by analyzing the CNAME records in your DNS records.
Make sure you have installed the necessary security patches and using the latest version of the core CMS and it's plugins as-well.
With this flaw a hacker is able to manipulate the price of the shopping cart and complete the purchase either for free or by paying a lesser amount. Put in place adequate data validation checks in the checkout flow, for example: data type checks, final amount checks and verification of transaction and billing amount after the purchase has been completed.
Such a loophole would be identified with Business Logic security testing. In the past it has been seen that 2 out of 5 hackers are 'Financial hackers' who try to exploit the system for their own financial gain.
It's super important to restrict access to the admin area/backoffice of your website. It is a favorite target for hackers and usually the first place they try to hack. You should leave no stone unturned for securing this area. Some suggested security measures are:
- Change the default admin URL to something unrelated and difficult for a hacker to guess.
- Restrict access to admin area so that only trusted IP addresses are allowed to connect
- Use Two-factor Authentication (2FA) for logging in
- Place HTTP authentication in addition to the default login & password
- Limit login attempts from a certain IP/Session
- Log all successful/failed login attempts
- Use a VPN to access this secure area
A rapid, accurately targeted, and effective response can minimize the overall damage to finances, hardware, and software caused by a specific incident.
The Incident Response team should be actively monitor critical server statistics like:
- Server Uptime
- Server Resource Utilization
- Unauthorized computer or data access
- Too many failed login attempts to website, backend, FTP/SSH etc
- Presence of a malicious application, such as a virus
- Presence of unexpected/unusual programs on the server
- Denial of service condition against data, network or computer
- Misuse of service, systems or information