Rules to Better Security

Hold on a second! How would you like to view this content?
Just the title! A brief blurb! Gimme everything!
Rules to Better Security
  1. [DEPRECATED] Do you use built in authentication from MS?

    Assuming you want:

    • Full blown user management
    • Nice Controls eg. Login, Change Password
    • To be able to implement authentication without a Security Consultant to check

    The options are:

    Option 1: ASP.Net Membership provider (original)

    Use their ugly table structure.

    Resilient to errors/attacks/omissions. "Better the devil you know, than the one you don't".

    So if it is simple, straightforward, standardized, integrated well with the existing platform, well documented, and sufficient for your current requirements - why would someone want to go and do something custom?

    No OAuth eg. Facebook

    Option 2: ASP.NET Membership provider (custom)

    (Inherits from Option 1)

    Typically if you want to use your own database tables (even non SQL)

    Easy. A typical implementation of a custom membership or role provider is a simple SELECT query against a database.

    Potentially a glorified ValidateUser/GetRoles method.

    Little messy if you don’t want full blown user management. Then you must leave a number of NotImplementedException methods (because you are not going to administer the store through the provider). In that case implement a base class, leave 28 methods not implemented, implement ValidateUser that takes two strings and returns a bool ;)

    Most clients have more concerns about them making mistakes in the custom security code, that would compromise the security of the application, then about using a bloated existing platform security mechanism correctly (when there are thousands of samples and documentation out there about how to do so correctly).

    Yes to OAuth eg. Facebook

    Hard to unit test.

    Option 3: Universal provider (Updated ASP.NET Membership provider)

    (Inherits from Option 1)

    Use their table structure.

    The default for VS 2012 Web Forms

    Universal Providers are intended for cases where you have an existing ASP.NET Membership Provider and you want to use it with another SQL Server database backend (other than SQL Server).

    Yes to OAuth eg. Facebook (out of the box)

    Option 4: SimpleMembershipProvider (New)

    (Inherits from Option 1)

    Use their table structure.

    The default for VS 2012 MVC 4 templates.

    Yes to OAuth eg. Facebook (out of the box)

    Note: If you need to use for Web Forms see Adding the SimpleMembership provider to an ASP.NET Web Forms app.

    Option 5: Use “Membership Reboot” on GitHub (a Gurus one) (RECOMMENDED)

    A solid, more flexible and open source alternative to the ASP.NET membership provider

    Typically if you want to use your own database tables (even non SQL)

    Description: Think twice about using MembershipProvider (and SimpleMembership)

    Source: https://github.com/brockallen/BrockAllen.MembershipReboot

    This OSS account management library manages these sorts of things for you:

    • PBKDF2 (Proper password storage)
    • Password reset
    • Account lockout for password guessing
    • Account confirmation via email, etc

    Bonus:

    • It is multi-tenant
    • It is claims aware (some complicated security thing from Microsoft that will revolutionize security)

    The design is different than ASP.NET Membership in that the security goo is packaged separately from the persistence (the database). You’d not normally need to change the security stuff (though it is extensible).

    You implement a repository if you want a custom storage (or you can just use EF and whatever EF-enabled DB you want).

    Option 6: Roll your own

    Risk, Risk, Risk... Unless you are a security consultant you are likely to leave a security hole.

    Of course you should not roll your own security. This option is building your own authentication and authorization routines to tie into FormsAuth (instead of using providers).

    The ASP.NET membership provider is wired in at a deep level in the ASP.NET pipeline. A roll your own solution loses you the benefits of leveraging this integration eg. In Silverlight and the WebAPI

    An example of completely removing ASP.NET Membership Providers: Kicking ASP.NET Providers to the Curb - And that actually works fine, but with one big, ugly, drawback. The site is able to authenticate and authorize as needed, but you drop in a few .ashx or other things like Elmah, CacheManagement, etc, and then tried to restrict access to them... it obviously is not able to.

    Note: Gurus use Windows Identity Foundation (and IdentityModel).

  2. Do you choose the best method of authentication for your situation?

    ​Authentication and authorization are complicated, and it is dangerous to try and implement it yourself.  Use this rule for a guide on choosing the right service or framework for your situation.​

    Simple and free

    If you're looking for a free solution, and most of your users already have an account with either Facebook, Google, Twitter or Microsoft, then an easy solution is to simply use these services for your authentication.  They all provide some external authentication endpoint, either using OpenId Connect or OAuth2.

    Advantages

    • Free
    • Simple to set up
    • Good user experience – often a one-click sign in
    • Plenty of documentation out there

    Disadvantages

    • People must have an account with an external service
    • No control over accounts or signup process
    • Profile management can tricky – do you use Google's display name or your own?

    Simple, managed as a service

    There are providers out there which offer to server identities and access control.

    Advantages

    • Much more control of access control and user profiles
    • Quick and easy to set up, with plenty of samples
    • Support

    Disadvantages

    • Costs money for more advanced features
    • Externally hosted, which may not be desired in some enterprises

    There are several providers to choose from – here are some of the more popular ones. Be sure to choose ones that fit your situation, as they each have different levels of compliance, features, support and pricing.

    Active Directory

    It's not uncommon for an organization to already be using LDAP, and IIS can supply windows identities out of the box. It's quick and easy to set up, but not very powerful and often all-or-nothing.

    Advantages

    • Good user experience
    • No management of users required at all
    • Leverages existing user storage
    • Companies like to use their Active Directory accounts everywhere

    Disadvantages

    • Role-based authorization can be difficult as the Active Directory API isn't simple 
    • Can be slow, depending on AD setup

    Full control

    The above options are about delegating identity access and authorization to another party, which may not be a good fit for your enterprise.  If full control over everything is required, then going with Identity Server (link to https://github.com/IdentityServer/IdentityServer3) for authentication and MembershipReboot (link to https://github.com/IdentityServer/IdentityServer3.MembershipReboot) for user storage is the best idea.  It does all the heavy lifting, allowing secure, robust and configurable storage of identities with industry standard authentication schemes.  The best part is you don't have to be a security consultant to implement it – though it is a good idea to have a solid understanding of security principals.

    Advantages

    • On-premises
    • Highly configurable
    • Uses industry-standard best practices for security

    Disadvantages

    • Steep learning curve
    • Takes a lot of development time to implement well
    • Requires vigilance to keep up-to-date to ensure any security issues are addressed as soon as they're raised.
     

    Roll your own

    One of the more common options for enterprises is to try and roll their own implementation.  This usually results in poor security and difficult to maintain code.

    Advantages

    • Developers feel like they're ninjas for a little while

    Disadvantages

    • Insecure 
    • Developers stop feeling like ninjas when they realise how complicated it is
    • High-maintenance 
    • Quickly turns into code that everyone wants to avoid
    • Very expensive to develop and maintain
    • Insecure – this needs to be mentioned again.  Security is very difficult to do correctly, and best left to experts.
  3. Do you colour-code your keys?

    ​​​Keys, we all have them. A key for the front door, a key for the garage, a key to the letterbox, and keys to your office… the list is often endless! How much time do you waste finding the correct key?​

    ​​If you allocate each individual lock a colour and then tag or colour your keys to match, you can save a lot of time and effort identifying the correct key.​

    keys 2.JPG
    Figure: Bad ​example - Figure: Bad Example - a key bunch with no colour-coding, total anarchy! 
    keys 1.JPG
    Figure: Good example - colour-coded keys with labels, perfect order.


    TIP: You can buy coloured key copies - so coding is even easier, no tags required!



  4. Do you stay safe against the OWASP Top 10?

    The Open Web Application Security Project (OWASP) is a non-profit charity organization whose sole purpose is to enable other organizations to develop applications that can be trusted.  Their most prominent piece of literature is the OWASP Top 10​ – a list of the most critical risks found in software.  It is a “living” list, which means it is updated as vulnerabilities become known and more or less common.

    OWASP Top 10 2013

    The current OWASP Top 10 states the following are the top risks for web applications today. Knowing and securing against these will give the biggest bang-for-buck in securing your website.

    • Injection: Being able to execute arbitrary SQL, LDAP or other code via your application
    • Broken authentication and session management: Exploiting weak login and session management.  See our other rules to better security
    • Cross-site scripting (XSS): Executing arbitrary JavaScript on a web page, often by reflecting unescaped user input
    • Insecure direct object references: Exposing internal implementation objects without proper access control
    • Security misconfiguration
    • Sensitive data exposure: Storing sensitive data in a way that can easily be retrieved and abused
    • Missing function level access control: Only applying access control to the UI, not when the secure section is accessed
    • Cross-Site Request Forgery (CSRF): Hijacking a user’s cookies to make requests on their behalf
    • Using components with known vulnerabilities
    • Unvalidated requests and forwards: Redirecting from a current site to an untrusted 3rd party, which may allow phishing to occur

    Other Resources 

    Protecting against these is a large topic in their own right.  There are plenty of resources with information on protecting against these, linked below:

    • Troy Hunt – Protecting your web apps from the tyranny of evil with OWASP 
      This video goes through the OWASP Top 10 in more detail, describing each risk, how to exploit it, and how to protect against it
    • OWASP Top 10 
      The OWASP home page is a little difficult to navigate but contains fantastic information on the risks and how to protect against them. Use the link above to get details on each of the vulnerabilities, with examples on attacking, “Cheat Sheets” for prevention and risk/impact assessment.

  5. Do you store your secrets securely?

    Most systems will have variables that need to be stored securely; OpenId shared secret keys, connection strings, and API tokens to name a few.

    These secrets must not be stored in source control in plain text – it is insecure by nature, and basically means that it is sitting.

    There are many options for managing secrets in a secure way:

    Bad Practices

    Store production passwords in source control protected with the ASP.NET IIS Registration Tool

    Pros:

    • Minimal change to existing process – no need for DPAPI or a dedicated Release Management (RM) tool.
    • Simple and easy to understand

    Cons:

    • Need to manually give the app pool identity ability to read the default RSA key container.
    • Difficult to manage production and non-production config settings
    • Developers can easily decrypt and access the production password.
    • Manual transmission of the password from the key store to the encrypted config file.
    Figure: Bad practice - Overall rating: 2/10
      ​

    Use Windows Identity instead of username/ password.

    Pros:

    • Minimal change to existing process – no need for DPAPI or a dedicated RM tool.
    • Simple and easy to understand

    Cons:

    • Difficult to manage production and non-production config settings
    • Not generally applicable to all secured resources. 
    • Can hit firewall snags with Kerberos and AD ports
    • Vulnerable to DOS attacks related to password lockout policies
    • Has key-person reliance on network admin
    Figure: Bad practice - Overall rating: 4/10
     

    Use External Configuration Files

    Pros:

    • Simple to understand and implement

    Cons:

    • Makes setting up projects the first time very hard.
    • Easy to accidentally check the external config file into source control.
    • Still need DPAPI to protect the external config file.
    • No clear way to manage the DevOps process for external config files.
    Figure: Bad practice -  Overall rating: 1/10

    Good Practices

    Use Octopus/ VSTS RM secret management, with passwords sourced from KeePass

    Pros:

    • Scalable and secure.
    • General industry best practice - great for organizations of most sizes below large corporate.

    Cons:

    • Password reset process is still manual
    • DPAPI still needed.
    Figure: Good practice - Overall rating: 8/10

    Use Enterprise Secret Management Tool – LastPass/ Hashicorp Vault/ etc..

    Pros:

    • Enterprise grade – supports cryptographically strong passwords, auditing of secret access and dynamic secrets
    • Supports hierarchy of secrets
    • API interface for interfacing with other tools.
    • Password transmission can be done without a human in the chain.

    Cons:

    • More complex to install and administer
    • DPAPI still needed for config files at rest
    Figure: Good practice -  Overall rating: 8/10
  6. Do you use a finger scanner to monitor access to secure areas?

    ​​​​​Do you know who is entering your premises, when and how? Keys or key-cards can be expensive, they can be lost and people can loan them to one another without any restriction.

    ​Finger scanners are a good way of monitoring and restricting access to secure areas. As every person’s fingerprint is unique, so is the access to your building.  There is no physical mechanism for unlocking the doors, which means you do not have to worry about lost keys or unauthorised access and it can keep a log of entry.

    SSW uses an Invixium fingerprint scanner. The user interface is easy to use, you simply hold your finger down on the screen and it will either allow or deny you access. Other finger print scanners like E-Key use a swipe function that is less intuitive for visitors. 

    The Invixium integrates well with our Control4​ Automation system.

    Scanner 2.jpg
    Bad example - E​-Key needs you to swipe your finger down, this is less intuitive.
    Scanner 1.jpg
    Good example - Invixium is easy​ to use, just hold down your finger on the screen to scan.
  7. Does your team understand the dangers of social engineering?

    As developers when we think security we commonly become fixated with issues in the code, out of date software versions or incorrectly configured firewalls. However, we miss one glaring vulnerability which there is no patch for... our users.​​

    Social engineering is a technique which mixes art and science to exploit common human behaviours to compromise information systems. The following is a classic example of social engineering performed over the phone.​

     


    There are numerous examples of social engineering ranging from phone calls, attackers posing as friends on social media, all the way to sophisticated attempts at phishing users with near-perfect clones of popular websites.

    social-eng.png
    Figure: ‘Do you think the average consumer could spot the phishing site?’ Source: Troy Hunt

    The only solution to social engineering is to train properly and prepare users about the dangers presented by and common techniques used by malicious individuals. For useful information on the topic reference the document ‘Avoiding Social Engineering and Phishing Attacks’ by the United States Computer Emergency Readiness Team  or the Pluralsight course Ethical Hacking: Social Engineering by Troy Hunt .

    With the above in mind, it is important to review regularly the information availed via search engines and standard operating procedures. Furthermore, it can be useful to test the readiness and alertness of staff by performing mock social engineering attacks.

    Take the following situation as an example: the CEO is out of town and decides to use an employee’s laptop left in the office on the weekend, the employee in question is messaged via Skype for their domain password. If the employee is aware of the risks, this poses the company then they would not send the requested credentials and follow proper procedure around reporting a suspected incident.