The first line of defense in any organization’s security policy is its staff/employees. Cybersecurity awareness training is imparted to all the employees as part of their onboarding process.
Seniors periodically conduct discussions aimed at keeping the staff updated on the latest vulnerabilities and best practices.
Employees are also encouraged and rewarded to bring up any short-comings in our security policy. This helps improve engagement in promoting cybersecurity awareness. LiteBreeze also sponsors paid training courses for interested employees.
Common web security vulnerabilities
The most common website security vulnerabilities are SQL injections, cross-site scripting (XSS), session hijacking, insecure direct object references, cross-site request forgeries (CSRF), Insecure transport layer protection, etc.
These vulnerabilities are primarily handled at the application level. Code reviews conducted by peers and seniors lookout for such common vulnerabilities and ensure that they are being handled appropriately.
Before selecting a framework to use for a project, it is analyzed for how well it handles the common vulnerabilities.
Securing data at rest and in transit
We believe that data security is of utmost importance as it not only leads to financial losses, but also to the loss of trust and unintended consequences to customers.
The GDPR regulations in force further enhance the importance of data protection. Data needs to be secured both at rest and in transit.
Data security in transit is ensured through SSL/TLS encryption methods. Data at rest is secured using encryption and restricted access.
Access to data and/or resources is protected using public-key authentication and web application firewalls.
Properly configured VPCs for the production resources also help improve access protection. DNSSEC can also be employed to protect against forged DNS data.
Mitigation of DDoS attacks
DDoS attacks are a threat to any application and result in application downtime, and more importantly, hit profitability and damaged reputation. CDN level solutions can be employed to mitigate these attacks.
Providers like Cloudflare, AWS Shield provides protection against DDoS attacks. These services also offer selective rate-limiting to block hard-to-detect DDoS attacks.
For applications hosting highly sensitive or confidential data, two-factor authentication may be used to restrict accidental data exposure.
For accessing areas of the application exposing such data, an additional level of authentication, like a passcode is requested from the user. This is a short-lived one-time code, which is sent to the user by SMS/email. Alternatively, we can make use of an app such as Google Authenticator.
Intrusion or threat detection
Use a tool like OSSEC to setup rule-based threat detection by reviewing different logs and patterns, as required. The OSSEC alerts can send notifications to mediums like Slack channel for effective and on-time manual intervention if required.
Restrict access to different resources like S3 buckets, RDS, Redis, etc, to the lowest level required. This would involve updating IP based access restrictions, bucket policies, security group rules, etc.
Enforce authentication for all services (ES, Redis, etc.), especially the ports/services open for public access. This should be irrespective of the application stage (testing/staging/prod). This will add another layer of security along with the firewall in AWS.
Setting up a monitoring and alarm system, where system resources are monitored for uptime, resource usage, etc. This would help detect and resolve issues at the earliest.
For server monitoring, we employ different services based on specific needs, like:
Server administration should always be managed by a single person (another person can be kept as a backup), to ensure that documented guidelines/checklists are followed when adding/updating permissions.
Strengthening access credentials and restricting access to them is at the base of the password policy.
Access credentials for different resources related to an application are documented in a Google doc, shared with only the project lead and network admin.
The credentials are shared with the other team-members only on a need-to-know basis. The password policy enforces the usage of strong passwords and periodic password rotations.
Using production data
Ideally, one should never have to use/copy production data into development or staging environments. Try to use fake/mock data for testing purposes.
In the rare case where a subset of production data is needed, document the usage/processing of the same, and try to anonymize the data if feasible.
Installing security patches or package updates wherever possible will definitely help with bettering system security and performance.
The aim is to keep the system updated, without breaking the applications.
Audit logs are maintained using custom logging on Google sheets to keep track of access and configuration changes.
As for projects deployed on the AWS cloud, basic audit log available from Amazon Cloudtrail can be coupled with custom logging, as required.
Third-party security audits
We assess and suggest competent firms or tools for third-party security audits, in scenarios where we feel the need for such an assessment or the client requests such an analysis.
As these companies focus on security assessment, this allows us to have an independent security analysis of the application.
NDA and DPA
We sign NDA with all our clients and development contracts also include a DPA (Data processing addendum) as part of the GDPR.
The DPA enables LiteBreeze to access the data added on the application intended for European nations, and use it as per the guidelines specified in the DPA clause. Additionally, the agreement with our employees also has an NDA.
With the NDA and DPA, you can rest assured that your business secrets and the applications data will be handled safely and securely by LiteBreeze and we’ll do our best to ensure any unintended use from our end.