The Inner Circle

Expand all | Collapse all

Hardening guidelines?

  • 1.  Hardening guidelines?

    Posted 19 days ago
    As many of you know, CIS does a great job in developing hardening benchmarks and CSP-specific images. I was recently talking to an enterprise who makes extensive use of this work and they said it would be really nice if one could find secure configuration guidelines for some of the other cloud services. Serverless, for example. With the hundreds of services that CSPs provide, this seems like a difficult task to stay on top of it, so I thought I would solicit ideas.

    For almost every security problem, somewhere, someone has developed a solution. Maybe the community could curate a repository of these guidelines. Maybe someone is doing it? Of course there is the problem of making sure the guideline is a good one. If you have thoughts, let us know!

    ------------------------------
    Jim Reavis CCSK
    Cloud Security Alliance
    Bellingham WA
    ------------------------------


  • 2.  RE: Hardening guidelines?

    Posted 18 days ago
    Hi Jim.

    When I hear a customer ask about security and serverless -  I tend to guide them towards security best practices in coding patterns/architectures since serverless services run code without provisioning or managing servers and the code is executed only when needed.

    OWASP Top 10 : Serverless Interpretation
    https://owasp.org/www-project-serverless-top-10

    Serverless on Amazon Web Services
    https://docs.aws.amazon.com/whitepapers/latest/serverless-architectures-lambda/security-best-practices.html

    Serverless on Microsoft Azure
    https://docs.microsoft.com/en-us/azure/azure-functions/functions-best-practices
    https://docs.microsoft.com/en-us/dotnet/architecture/serverless/

    Misc
    https://snyk.io/blog/10-serverless-security-best-practices/
    https://www.serverless.com/blog/fantastic-serverless-security-risks-and-where-to-find-them
    https://hands-on.cloud/security-best-practices-for-serverless-applications/
    https://blog.checkpoint.com/2020/04/29/9-serverless-security-best-practices-you-must-read/
    https://www.cyberdb.co/serverless-security-best-practices/
    https://github.com/puresec/sas-top-10
    https://documents.trendmicro.com/assets/white_papers/wp-securing-weak-points-in-serverless-architectures-risks-and-recommendations.pdf


    ------------------------------
    Simon Kok
    ------------------------------



  • 3.  RE: Hardening guidelines?

    Posted 18 days ago
    That is definitely a good list for Serverless!

    ------------------------------
    Jim Reavis CCSK
    Cloud Security Alliance
    Bellingham WA
    ------------------------------



  • 4.  RE: Hardening guidelines?

    Posted 18 days ago

    I don't think there is an "easy" answer to this, perhaps explains the meagre responses so far for such a core question. Although there are companies offering automated configuration checks of some cloud services, it will be very hard for 3rd parties to create and maintain such configuration information.

    I'd suggest these are "interesting models" of what you would want :

    (1) In  ACSC IRAP the audit reports include caveats required in the configuration of the certified service to bring it up to the Australian Government's Information Security Manual standard required. For example the auditors recommended enabling encryption with various AWS EC2 related services when I reviewed the AWS report (AWS are very open about with the contents of AWS Artifact, more so than the various certifications require AWS to share).

    (2) I would also note that the Microsoft guidance for handling UK Information at "OFFICIAL" in O365 which was done a few years back was also a good example of guidance.

    https://www.ncsc.gov.uk/blog-post/securing-office-365-with-better-configuration

    There are various aspects of these sources of configuration advice that make this advice possible.

    (a) Focus on the client's need not the suppliers need for security (CSA STAR seeks to do this too).

    (b) A clear baseline (Austalian ISM, OFFICIAL handling requirements) or certification/compliance goal to meet. This acts as a "substitute" for a threat model, whilst placing restrictions on the sensitivity of material which is covered in theory caps the total risk exposure (UK OFFICIAL covers basically the day to day working documents of the UK public sector that aren't suitable to be public, but not material relating to sensitive military or law enforcement activity) . As without a compliance style goal, other documents might end up caveat-ed with "if X is a concern do Y". NCSC have tried to use principles to drive this and encourage users to think about security, but whilst it might lead to sophisticated users, I'm assuming you are after advice with more technical "meat", or more fleshed out than the 14 principles.

    (c) Governments were paying for it. Not sure this is strictly necessary, but public sector constraints may make it easier both to justify the expense to protect data about members of the public, and provides a certain amount of scale (the UK government has a lot of O365 users, although I was throwing these documents at a lot of people who should have read it already in a previous role, so not clear if the UK maximised the value they got from their engagement with Microsoft Professional Services, but they tried). Either way the take away is there is a clear way to finance the production of the advice.

    (d) Supplier capability & engagement. It requires a certain amount of sophistication on the part of suppliers. IRAP had only certified 21 services when I was reviewing it, this likely reflects the expense and work involved in certifying the services, but getting to the level where the supplier can assist in hardening, or admit when a service is not suitable, requires maturity in their approach to security. I believe supplier engagement is really key (not sure how this works with CIS), Amazon AWS are the only people who can supply enough detail of their encryption processes to allow an assessment to say if their encryption service is suitable for any given level of threat. But as always a critical external eye is needed, in case they overlook, or embellish as aspect of their security stance.

    IRAP has an ongoing review process built in, this would clearly be needed to keep guidance current.

    If I think of AWS, or O365, the complexity of the offerings makes it really hard to generalise. I can see a clear case that O365 users want the more expensive license for a CIS "best practise" guide, but some of the Microsoft guidance the NCSC reference is clearly focused on a "second best"  licence, although Microsoft will sell some of the services covered in their more expensive licenses as an add-on to lower tier licensees. I think there are separate issue with over complex security tiers in products, but that is another discussion, suffice to say I like Google's simplicity in this regard, where you can opt for things like mandating partner's email servers have valid TLS certificates, but Google basically provide identifying malicious activity as part of their core offering. But that aside the complexity in these offering makes configuration advice more complex, and the cost model is very different from say employee time spent hardening on premise equipment to CIS benchmarks.

    Within something like the CSA CCM/CAIQ type approach, I could imagine one could ask audited service to note where they have optional features, or configuration, that are relevant to a given control or group of controls. That could be recorded in the matrix, and that would provide a method one could refresh them on a regular basis to ensure it is still current and appropriate.

    On a more immediately practical or more urgent basis, in a previous role, I maintained brief security pages for both suppliers (including Cloud suppliers) and for products and dependencies used in that companies solutions or software products. It was maintained in a Wiki (intentionally easy to both read and maintain by other employees or contractors, but with clear audit log, and notification of changes). However the emphasis was always on linking out to public sources of information I had found on the security. As you want the least possible content to maintain in-house. Indeed where ever possible we would update Wikipedia, or contribute to the security advice from projects themselves, rather than produce in-house advice. Since that gave us the ability to get assistance outside our own resources in maintaining it. One could take the view that we should perhaps consider maintaining Wikipedia, and that the most effective way to share knowledge in a communal fashion is probably to ensure there is a "security" section on all Cloud Service Wikipedia pages which list incidents of note, vulnerabilities of note, and notes where advice on secure use and configuration may be found, which is basically what I recorded internally, along with details on internal use of products. Since Wikipedia forbids original research, it might make sense to link back to resources like the CSA threats reports, which are a good source of material on past incidents



    ------------------------------
    Simon Waters
    Founder
    Insufficient Entropy
    ------------------------------



  • 5.  RE: Hardening guidelines?

    Posted 18 days ago
    I had thought about the idea of creating a wiki for cataloging these types of guidelines but I did not think about going directly to Wikipedia to maintain this type of data. Definitely something to ponder. I think that scouring the Internet for hardening guidelines and curating them is certainly more realistic than building them. Possibly we could have a 5 star review system or Reddit-style upvotes so the community could get a sense that a given hardening guideline is credible?

    Some of you familiar with my back story may know that I created SecurityPortal.com back in 1998 and for a short while it was the Internet's go to site for bugs, advisories, patches, incidents, best practices, etc. My main linux security guru back then, @Kurt Seifried, works at CSA. We could possibly create a mini-version of that website if we created the right scope and had enough volunteers to contribute.



    ------------------------------
    Jim Reavis CCSK
    Cloud Security Alliance
    Bellingham WA
    ------------------------------



  • 6.  RE: Hardening guidelines?

    Posted 18 days ago
    Another aspect of this is also documenting what is possible, e.g. via the web/CLI interface and/or documentation. For example, logging and auditing are often far more powerful than you'd think at first blush in many cloud services, but often have some limitations that can be a challenge, for example, Google's GSuite admin interface for email log search really only goes back 30 days, beyond that, you can only search for Recipient, but you also need the message ID, which you probably don't have if you're searching for some specific email.

    Possibly documenting what capabilities exist and where to find out more (e.g. where the web interface is, what the CLI tools are called, links to the official documentation) would be an additional parallel workstream to finding security/hardening documentation. An obvious next step would then be to document limitations, best practices, pros/cons (e.g. AWS CloudTrail logs are comprehensive but you'll need some sort of processing tool because it's very high volume) and so on. I know I already have a pile of random notes for such things, I would assume I'm not the only one.

    ------------------------------
    Kurt Seifried
    Chief Blockchain Officer and Director of Special Projects
    Cloud Security Alliance
    [email protected]
    ------------------------------



  • 7.  RE: Hardening guidelines?

    Posted 18 days ago
    Hi Kurt.

    With security auditing tooling - specific with Amazon Web Services, there's a service called AWS Inspector - you essentially install an agent on the EC2 instance and then let it do it's scheduled audit on OS patching and also benchmarks on server hardening (CIS benchmarks).

    The AWS Inspector report is great as it also provides information on how to remediate.

    From a compliance perspective, you get an idea on the number of EC2s running that are in compliance from a OS patching perspective and hardening perspective.

    ------------------------------
    Simon Kok
    ------------------------------



  • 8.  RE: Hardening guidelines?

    Posted 18 days ago
    That's part of the challenge, just from the AWS main interface alone the security-specific section:

    Security, Identity, & Compliance

    1. IAM
    2. Resource Access Manager
    3. Cognito
    4. Secrets Manager
    5. GuardDuty
    6. Inspector
    7. Amazon Macie
    8. AWS Single Sign-On
    9. Certificate Manager
    10. Key Management Service
    11. CloudHSM
    12. Directory Service
    13. WAF & Shield
    14. AWS Firewall Manager
    15. Artifact
    16. Security Hub
    17. Detective
    18. AWS Audit Manager
    19. AWS Signer
    To say nothing of each service that has various security controls/properties/capabilities (e.g. S3 has a huge pile, as does EC2). Just listing the capabilities for each of the big 3 cloud providers would be a huge pile of work (but again knowing what capabilities exist more easily sure would be nice). I've often wondered about how to secure X only to find X has exactly those security controls built into it... but finding them presupposes that you even know they exist.

    ------------------------------
    Kurt Seifried
    Chief Blockchain Officer and Director of Special Projects
    Cloud Security Alliance
    [email protected]
    ------------------------------



  • 9.  RE: Hardening guidelines?

    Posted 18 days ago
    I remember the SecurityPortal.com site!   SecurityFocus.com is still running too.

    The one that I used the most previously was Peerlyst (but that has since been shelved last year). :(
    https://www.peerlyst.com/

    ------------------------------
    Simon Kok
    ------------------------------



  • 10.  RE: Hardening guidelines?

    Posted 16 days ago

    The Wikipedia team type approach is a well trodden path. There is a computer WikiProject that aims to document aspects of computing on Wikipedia including "security", but not sure how the community aspects there work.

    Taking a look AWS EC2 Wikipedia article has a little information on incidents affecting EC2, but precious little on preventing them. So would seem ripe for a refresh. The ban on "original research" means we can only link existing research, and give ideas backed by solid evidence, but if anything that is probably useful discipline rather than a barrier to communication. If I'm inspired I'll give it a go and see if the "revert bots" or Amazon leap in to try and undo the changes. 

    The page is ripe for some other tidy up, as it still reads a little like sales material and not as encyclopedic as it should. There are some objections about it being a brand, or product, but I don't think that is appropriate, I dare say Microsoft Windows and Hoover have pages, I think notability is what matters, and being approved by key government security certifications, and sheer scale of impact mean that issues with EC2 escalate.



    ------------------------------
    Simon Waters
    Founder
    Insufficient Entropy
    ------------------------------