Security Best Practices

by Ped Rahmati


Security? Why is it important?

    Chances are, if you work in tech, you, or someone you know, is legally responsible for assuring your technology team understands and conforms to security laws, regulations, and mandates within the markets you operate. In many countries, compliance needs to be registered when performing normal business activities, for example: when opening a merchant bank account. In others, the law spells out the conditions, and each company that meets said conditions would be legally culpable. Every business has their own risk posture and acceptable risk level based on various factors (type of data at risk, size of operation, regulatory environment, investor appetite for risk).

    This article won't tell you what to do, but I'll attempt to help you understand the details enough to determine your risk posture, hopefully with enough context to determine next steps if needed. We’ll cover some common attack surfaces and attack vectors, along with some best practices to keep in mind. There are many options, some in the extreme. You’ll need to determine how far you need to go to secure your user data and your business. However, this article is only a starting point on your journey to proper security practices.

    Regulatory details around the world are varied, though they tend to follow some general patterns and themes. Here are some examples:
    Some general standards and requirements in our industry:
    Keep in mind: you may have very unique security concerns due to the nature of your business or your operating conditions that can't be appropriately covered in a single article. Should that be the case, or you're unsure if it is so, please seek out a security professional or consultancy to assist at least in determining this factor.

    To ensure your policies, practices, and automation are in place and working, not only should you test, but you should audit, by engaging a 3rd party service. While costly, these audits are an investment in legally defensible risk mitigation for your company, as well as marketable assets to advance sales, partnerships, and other engagements.

    Equally important, security needs to be usable; there’s a balance between coverage and ease of use. Your business needs to be able to run without tremendous interruptive processes or exorbitantly priced solutions.


    Attack Vectors & Defense Strategies

      Attack vectors are mechanisms that a bad-actor could take advantage of to access, destroy, or otherwise compromise assets that your company does (or should) intend to protect.

      Physical

      • Wire Tap / Port Tap - utilizing an electromagnetic device to read and transmit and/or record data in transit over physical medium.
      • Social Engineering - using deception to misrepresent identity and/or access level due to gain physical or virtual access.

      Common defense strategies:
      • If you have a receptionist and waiting / seating area, you’re already fairly well off (likely have a sign-in or host hand-off process).
      • Open offices are challenging; you have to identify sensitive areas (tech, finance, human resources) and ensure guests are escorted (e.g. building contractors drilling for 3G repeaters; former employees stopping by to say hello).
      • In any type of manufacturing or warehouse facility, ensure CCTV coverage of all entry/exit points, and if possible clearly delineate guest-accessible areas vs contractor accessible areas vs employee accessible areas.
      • For door access, keypads aren't great; card access is OK, but biometric access is better.
      • All devices (down to USB hubs, USB-HDMI converters, mice) should be provided by your IT team, not BYOD. If you have a BYOD policy, ensure it spells out specific responsibilities of individuals choosing to do so (including applying patches, using anti malware protection, etc.).
      • Obfuscate! Windowless server rooms are better than glass-walled, unless all your equipment is housed in closed racks.

      Network and Digital Services

      • Malware - malicious software that can activate immediately, run in the background, or remain dormant until a predetermined date has passed or event has occurred.
      • Phishing - using a legitimate-looking email or other electronic communications to entice an end user to provide passwords / tokens / access keys / etc.
      • Wardriving - with commonly available wireless network equipment, attempt remote access to protected wifi end points.

      Common defense strategies:
      • Disable SSID broadcast for your wireless networks, and ensure all default accounts and passwords on your network devices have been changed.
      • Guest WiFi Access - separate SSID, with no addressable routes to internal systems, with a daily or weekly password reset.
      • Satellite offices - point-to-point tunnels and VPN clients for internal system access.
      • On prem equipment (and staff laptops / desktops) should be whitelisted not DHCP’ed. Ideally, BYOD devices with network connections would get the same treatment.
      • Firewalls and gateways should be in place (and updated) - this often requires support contracts to keep threat detection and filtering current.
      • Sensitive systems should be segmented into different subnets from each other, deskspace / wifi end-points, and guest end-points.
      • Acceptable Usage Policies MUST be in place, distributed, and confirmed (signed form) by each employee (or non-employee with network / equipment access), preferably on an annual basis.
      • Try to centralize authentication, and if possible, authorization (there are cost-effective options out there, such as openLDAP, freeRadius, etc.).
      • Patch your bios, OS, 1st and 3rd party software, frameworks, compilers, interpreters, and libraries. Subscribe to patch notifications, and follow through when notified.
      • For sensitive systems, use MFA (multi-factor authentication), and only provide access on an as-needed-only basis, resetting the password after each use (e.g. AWS root account).
      • Data Lake should be highly privileged access only, basically to your database engineering person or team. Data Warehouse PII needs to be anonymized, but can maintain uniqueness.
      • Obfuscate! Instead of mail.mydomain.my, use nnn.mydomain.my or rmsfpk.mydomain.my (for any publicly addressable internal system: email, ftp, etc.). This adds another barrier for a malicious actor to compromise your systems.

      Software Architecture

      • XSS (cross site scripting) - utilizing weaknesses in your website's scripting and form implementation, malicious users can inject their own scripts onto the page, which then gives them full control of your page's behavior.
      • SQL Injection - using an unhardened data access layer, a user can inject database commands which could be used to render pages to inject malicious scripts, or insert, update, and delete your data.
      • Session Jacking - the practice of using session keys stolen from a legitimate client to impersonate that client.
      • Man-in-the-middle - a malicious software / hardware instance between a legitimate client and a legitimate server, responding to both as the original would, but capturing or surgically modifying the payloads while responding.

      Common defense strategies:
      • Make sure your integrated service providers have the appropriate certifications and reports; look for some type of ISO 27000 compliance and SOC 2 or 3 reports.
      • PCI SAQ - something your payment gateway provider will likely ask for if you have an ecommerce presence. These require a signature to confirm compliance, and as with anything you sign, you need to fully understand what you are agreeing to.
      • Use https for all web based interactivity you provide, including assets. No excuses, it’s now free (letsencrypt, AWS ACM, etc.), and the SEO benefits justify the effort alone.
      • Avoid using sequential identifiers to retrieve PII (use a UUID instead).
      • Use signed cookies, so end users can’t mess with cookie values without you knowing (including session key cookies).
      • Implement role based authorization for internal admin tools, providing access to functionality based on the user’s role. A marketing person won’t need access to a user’s shopping cart attributes, and a customer service person won’t need access to discount setting.
      • Ensure code reviews are practiced, and that part of the review is to assess impact to security.
      • HASH. ALL. PASSWORDS. Hashing isn’t encrypting. Use salted hashes; salt pre-hash; salt should be semi-unique row-to-row, not stored in nor generated by your code.
      • Avoid storing keys or credentials in code or config files within your widely-available repositories. Establishing a separate repo for DevOps and/or Tech Department Head(s), which is wired into CICD and codebase to be retrieved from environment variables, is one way to achieve this.
      • Penetration testing is a must. No matter what, you do have pen testing. Either you do it, or your users (including those with ill intent) will.
      • Obfuscate! Forms and form-element names and IDs (e.g. ‘password’ is a bad field name, ‘h8ds9vj’ is better) should not be human readable.

      Some good news! Most frameworks (rails, laravel, .net, etc.) provide built-in mechanisms to avoid common attack vectors, and also implement some of the suggested approaches to some degree, but ALL of them allow you to circumvent and create something less secure. But you can’t rely on hope. Your software is likely your widest attack surface, and you need to TEST EXTENSIVELY! You’ll want to crawl your website, even the portions requiring authentication, to detect these common vectors (typically in a test environment devoid of real user data). Luckily, there are services which can help you with this. You’re not alone!

      In conclusion:
      • Understand your stance, and how it relates to your regulatory requirements.
      • Use common sense, process can’t be very cumbersome for low-risk, high-frequency access.
      • Protect your company from yourself / your staff!
      • Limit access to those who require it on a regular basis. Others can ask for data from those who already have access for ad hoc situations.
      • Obfuscation is usually free. Start there!
      • Follow guidelines and common design patterns for your chosen software framework.
      • Use enterprise hardware, chances are it’s been hardened in ways that consumer hardware hasn’t.
      • Know your vendors' patch cadence, and if necessary, patch daily. Build this habit early.
      • Make sure you pen test, and scan your infrastructure for vulnerabilities. Ideally, build it into your CICD. Not knowing is an unacceptable risk for most businesses.

      Good luck in your journey into building more secure technology platforms and practices. Your company, and your end-users, will thank you for it.