《GitGuardian:机密管理成熟度模型白皮书(英文版)(30页).pdf》由会员分享,可在线阅读,更多相关《GitGuardian:机密管理成熟度模型白皮书(英文版)(30页).pdf(30页珍藏版)》请在三个皮匠报告上搜索。
1、Secrets ManagementMaturity ModelAs organizations are looking to develop secure digital services faster,the DevSecOps movement has seen its popularity soar,with the promise of breaking the silo between development,operations,and security.Although many tools and practices have emerged to support the d
2、evelopment of “secure by default”applications for the cloud,the matter is still far from resolved.Secrets management,in particular,remains a thorny issue even for the most mature organizations.With hyperconnected systems,secrets have become omnipresent along the software development cycle,making the
3、 legacy security perimeter obsolete.With this document,we wish to contribute to the consolidation of knowledge around DevSecOps practices by introducing a secrets management maturity model.Information security leaders who would like to start by doing a quick assessment of their security posture can
4、take the following five-minute questionnaire(its completely anonymous):Secrets Management Maturity QuestionnaireThe result chart at the end will provide an overview of their current level of secrets management maturity,complete with weaknesses and strengths,and invite them to jump directly to the mo
5、st relevant part of this white paper.A maturity model is a tool that helps people assess the current effectiveness of a person or group and supports figuring out what capabilities they need to acquire next in order to improve their performance.-Martin FowlerA DevSecOps ChallengeNo Silver bulletA qui
6、ck look at the Secrets Management PanoramaKey considerations for secrets managementThe ModelDeveloper environmentSource code management(source code&Infrastructure-as-Code)CI/CD pipelines&artifactsRuntime environmentBonus:KubernetesOther considerationsAccess controlsSecrets qualityLogging and auditin
7、gSummaryAbout GitGuardian468722232424242628A DevSecOps Challenge01Whitepaper|Secrets Management Maturity Model5A DevSecOps ChallengeA modern application uses many external resources(databases,third-party SaaS applications,other microservices)that require credentials.Not only that,but the
8、development cycle itself sometimes requires the interaction of many entities and services which can be running on the same machine or on the other side of the world(eg.a local development instance of a microservice using a remote database,a testing CI pipeline querying a third party API).All these i
9、nteractions rely on secrets to work as intended,and only as intended.A cornerstone of security in general,secrets are essential in keeping information and compute resources secure and out of threat actors reach.Well-kept secrets,such as passwords and other authentication credentials,ideally allow th
10、e right identities(human or machine)to access the right thing at the right time.The consequence of leaked credentials can be devastating.Exposed secrets are the low-hanging fruits hackers always look for to gain initial access or privilege escalation,as recently again demonstrated by major attacks a
11、gainst Uber(2022)or Co decov(2021).For organizations,the adoption of DevOps and agile practices completely reshuffled the cards when it comes to the notion of a“security perimeter”.Todays hyperconnected systems bring an immense challenge to security in general and secrets management in particular si
12、nce the number of credentials in use has grown exponentially.Developers,operations,and application security engineers are all faced with this increasing complexity and try their best to balance the risks and rewards of this process across the development cycle.Managing secrets is easier said than do
13、ne,and there is no one-size-fits-all due to the diversity of use cases.Hence the importance of a maturity model.No Silver bullet02Whitepaper|Secrets Management Maturity Model7No silver bulletBetween development secrets used by developers,machine authentication at the build and testing phase,applicat
14、ion secrets,infrastructure secrets,etc.,secrets can vary widely in origin,nature,and function.Their sheer number in software companies means that there simply cannot be a one-size-fits-all solution for managing them.Even for the most mature DevSecOps organizations or teams,secrets management is very
15、 difficult to do well,because it is a matter of striking a subtle balance between security and flexibility.This second point is very important for one simple reason:in modern development teams,secrets are used by all people&assets.On the ground,it is easy to see that there is a gap between theory an
16、d practice when it comes to handling and sharing credentials in a team,a department,or an organization.For example,the organization may pay for a cloud-based secrets manager,a vault,or maybe even for a dedicated team to administer these tools,which makes it falsely think it has solved this problem.B
17、ut under further scrutiny,it would realize that the long-lived credentials are also stored on the devs local machines for convenience.Making it hard to use secrets will inevitably lead to the bypassing of the protective layers in place.Whitepaper|Secrets Management Maturity Model8No silver bulletExa
18、mple:Uber(2022)In this attack scenario,the attacker found a Thycotic admin username and password hard-coded in a Powershell script on a network drive.Thycotic is a Privilege Access Management solution that stores secrets for accounts with high privileges for a multitude of assets:in that case,AWS,GC
19、P,GSuite,Slack,SentinelOne,HackerOne,and more.A single hardcoded credential was enough to obtain valid accounts for all these systems.This is why having a holistic approach to secrets is essential to account for their double-edged nature:secrets are at the same time a major risk that needs to be clo
20、sely monitored,but also an indispensable commodity to spin the famous DevOps infinity symbol()without friction.A Quick Lookat the Secrets Management Panorama03Whitepaper|Secrets Management Maturity Model10A Quick Look at the Secrets Management PanoramaIn the secrets management model,we refer to the
21、various ways secrets can be made available from the most rudimental to the most advanced:Hardcoded in source code and templates Grouped in common,unencrypted files,such as.env,outside of the git repository Encrypted in a GitOps or sealed secrets approach,with decryption key stored in a vault Stored
22、in a vault and distributed through a secrets management service Generated just-in-time and ephemeral,through a complex secrets infrastructureAll the major VCS platforms(GitHub,GitLab,BitBucket),CI/CD vendors(CircleCI,Jenkins,TravisCI,etc.),and cloud providers(AWS,GCP,and Azure)come with their own se
23、crets management facility.More precisely,they offer a mechanism for storing sensitive values(vault service),and a mechanism to inject and serve these credentials when required(secrets management service),although their exact features can vary.Popular options to store,manage and synchronize secrets a
24、cross environments include HashiCorp Vault,Akeyless,and Doppler.They offer the advantage of being an external single source of truth for all the aforementioned services while implementing state-of-the-art encryption and access controls.Side-noteIn this paper,we have chosen to distinguish between thr
25、ee functions of secret management tools,which are often overlapping in commercial offerings:A vault service offers a secure,centralized key store with tight access controls.A secrets management service allows to create,serve and rotate credentials(notably,dynamic or ephemeral secrets).A key manageme
26、nt system(KMS)service allows the management of cryptographic keys.Whitepaper|Secrets Management Maturity Model11A Quick Look at the Secrets Management PanoramaBut again,the variety of use cases for secrets makes it very difficult to make all the DevOps cycle phases dependent on one single service.Th
27、e state of secrets management in modern software development shops is always a mixture of ad-hoc solutions,depending on which link of the chain is considered and the level of maturity.One common flaw of secrets management,in general,is that it fails to account for human error.A developer hard-coding
28、 an API key to test a program on their local machine and then accidentally committing this change to a code repository would have a very difficult time figuring out:Multiple back-and-forths with CloudOps or SRE and AppSec engineers would be needed.No matter the maturity of processes,seniority of eng
29、ineers,the rigidity of policies,or the sophistication of tools,secrets will be hardcoded somewhere at some point.In other words,failure modes should be an integral part of secrets management thinking.Lets look at the details of what this means.1.he leaked a secret2.how to revoke that secret 3.how ro
30、tation might impact downstream services dependent on that credential.Key considerations for secrets management04Whitepaper|Secrets Management Maturity Model13Key considerations for secrets managementFirst,we need to define what we consider to be part of secrets management and what we consider to be
31、out of scope,even if related to the domain.In a holistic approach to secrets,we consider essential to have visibility over an organizations perimeter.Therefore,being able to monitor secrets not only where they are supposed to be,but(more importantly)where they really are is a must-have.You just cant
32、 protect what you dont see.In the previous example,it is easy to understand that despite having a solution to manage secrets across the organization,the lack of secrets detection is defeating the very purpose of this solution in the first place.While the two tools have distinct usage,they share the
33、same objective:keeping secrets secret.From the same perspective,we should remember that managing secrets is a security feature.Since security cant be achieved without incident response capabilities,Failing to acknowledge errors and misbehaviors is a recipe for failure in any security context.Secrets
34、 are no different and taking into account the human factor is essential:the most recognized industry reports1,2,as well as our own data,consistently point at human errors as the number one source of breaches and leaks.Preparing for when(not if)leaks happen must be part of the secrets management proc
35、ess.In other words,if secrets management is about protecting your secrets,it cannot go without secrets detection.remediation is also a core aspect of sane credentials management.1 Cost of a data breach 2022,IBM 2 2022 Data Breach Investigations Report,Verizon Whitepaper|Secrets Management Maturity M
36、odel14Key considerations for secrets managementTo sum up,our model considers that secrets detection and remediation are unvoidable aspects of secrets management.It should help teams make their goals more explicit when it comes to:Secrets scopeWhat kind of action is allowed by a certain secret?Remedi
37、ation proceduresWhat happens after a secret is leaked?Secret lifecycleCreation,lifetime(for how long is it valid?),regular rotation.How do we make sure we know when a leak happens?Secrets detectionThe Model05Whitepaper|Secrets Management Maturity Model16The ModelWe propose a 5 level maturity model f
38、or secrets management,detection,and remediation in 4 main areas of the software development cycle:Developer environmentSource code managementCI/CD pipeline&artifactsRuntime environmentsSplitting the DevOps cycle into distinct phases is necessarily an arbitrary decision,and even more so when talking
39、about something as transversal as secrets.Therefore,we decided to separate it according to the following logic:This section corresponds to the daily activities of the developer and how they manage to get access to and share the secrets they need to test their programs and scripts.As awareness about
40、the problem of secrets sprawl rises,some developers encrypt secrets before sharing them,and potentially shield their working environment from leaks with pre-commit hooks.But thats not all:developers are also on the front line when it comes to secrets remediation.Progressively involving developers in
41、 the remediation process is a significant step toward a mature secrets management program.This is also where we chose to talk about the evolution of secrets rotation policies and process,eventually leading to full automation.Developer environmentWhitepaper|Secrets Management Maturity Model17The Mode
42、lThis section is about how source code and templates(Terraform,Dockerfile,etc.),at a global level,can be shielded from secrets sprawl.We consider that secrets found in IaC templates are probably giving access to cloud resources like storage,IAM systems,etc.and should be removed first.Central reposit
43、ories administrators are in charge of setting up the right controls to continuously scan for secrets before they can be considered compromised.This is also where we chose to talk about the evolution of the remediation process.This section is about the build process and the resulting artifacts.It is
44、not uncommon to find secrets leaked in Docker images or even binaries.These should be removed in the first place,and the build process itself should eventually include a scanning step to make sure that no secrets can find their way into the artifacts or the build logs themselves.Also,the credentials
45、 used in the build process should be rotated and fine-tuned to a very restricted scope to prevent potential lateral movements.Finally,at runtime applications also need secrets.The classic examples would be a database connection string for a web app or third-party API keys.Provisioning these secrets
46、at runtime requires the same thoughtful design decisions about secrets lifetime,scopes,rotation,and,maybe more importantly,how to deal with a leak without causing downtime.We observed in the past that a leak could force engineers to temporally shut down part of the production,with direct consequence
47、s for the business.Preventing such an outcome definitely has its place in a secrets management mindmap.Source code management(source code&Infrastructure-as-Code)CI/CD pipelines&artifactsRuntime environmentWhitepaper|Secrets Management Maturity Model18The ModelLevel 4ExpertsLevel 3AdvancedLevel 2Inte
48、rmediateLevel 1BeginnersLevel 0UninitiatedLevel 0 No processes or tools for managing secrets secrets sprawl in the SDLC.No detection(and remediation)in place.Level 1 Secrets are unencrypted at rest but grouped in configuration files shared across multiple teams.Scanning for secrets is triggered manu
49、ally at times,but developers are rarely involved in remediation.Level 2 Secrets are checked encrypted into repositories with decryption keys stored in a secure vault.Secrets scanning and rotation are performed periodically.Level 3 Secrets are scoped,stored in a vault and shared using a secrets manag
50、er.Automated detection on shared repositories and final artifacts is continuous.Level 4 Secrets are scoped,stored in a vault and shared with a secrets manager.Detection is preventive and integrated into development workflows(local workstations,CI pipelines,etc.).Developers remediate their incidents.
51、Whitepaper|Secrets Management Maturity Model19The ModelLEVEL 0 UNINITIATEDLEVEL 1 BEGINNERSSecrets managementSecrets detectionSecrets are shared in clear text through private channels and stored unencrypted in local config files.Secrets can be found anywhere in files.They are checked unencrypted int
52、o private repositories.Secrets are embedded in final artifacts such as container images.VCS and 3rd party(e.g.code quality tools)access tokens are harcoded in build scripts.Secrets are embedded in deployment scripts.Sensitive variables are printed in server logs.No detection in place.Developerenviro
53、nmentsCI/CD pipelines&software artifactsRuntime environmentsSource Control(Source code&Infra-as-Code)No detection in place.No detection in place.Low or no observability on production secrets.No rotation planning or strategy.Secrets managementSecrets detectionSecrets are unencrypted in config files b
54、ut can be encrypted before sharing with other developers.Secrets are grouped in config files and accessed using environment variables.IaC secrets are stored externally by the cloud services provider(e.g.AWS,GCP).Source code and IaC templates are manually and periodically scanned for secrets.High-sev
55、erity incidents are remediated with limited help from developers.Final artifacts do not contain any secrets.Pipeline secrets are stored in the build system.Sensitive variables are redacted from build logs.Secrets are grouped in a common config file.Sensitive variables are redacted from logs.Secrets
56、are not scoped by environment.No detection in place.DeveloperenvironmentsCI/CD pipelines&software artifactsRuntime environmentsSource Control(Source code&Infra-as-Code)Build outputs(e.g.,Docker images)are scanned for secrets manually before a release.Production secrets are monitored through a single
57、 pane of glass,but there is no rotation strategy.High exposure riskHigh exposure riskWhitepaper|Secrets Management Maturity Model20The ModelLEVEL 2 INTERMEDIATELEVEL 3 ADVANCEDSecrets managementSecrets managementSecrets detectionSecrets detectionSecrets are stored in a vault and shared through a sec
58、rets manager.Developer environment secrets are correctly scoped.Secrets are stored in a vault and shared exclusively through a secrets manager.Secrets rotation policy is well defined.Secrets are no longer embedded in the current source code revision.Secrets rotation policy is well defined.Pipeline s
59、ecrets are stored in vault and loaded using a secrets manager.Secrets are scoped;permissions follow the principle of least privilege.Secrets are stored in a vault and dynamically loaded from a secrets manager.Secrets are scoped and access ismonitored/logged.Informative scanning is enforced for all b
60、ranches(feature,hotfix,etc.)in CI pipelines.Production secrets are scheduled for regular rotation.All repositories are continuously scanned for hardcoded credentials.Collaboration on incident remediation is mandatory for all developers.Historical incidents are being triaged.Secrets are encrypted and
61、 checked into repositories(master key is stored externally).Secrets are stored in the build process.Secrets are scoped;permissions abide by the principle of least privilege.Secrets(or master decryption key)are stored in a vault and dynamically loaded with asecrets manager with minimal access control
62、s.Scanning is triggered manually at times by developers on their local workstations.Scanning before pushing code(pre-commit/pre-push)is adopted by security champions.Developers are systematically involved in the remediation process.Critical repositories are continuously scanned at the pull/merge req
63、uests stage.Developers contribute to remediation but it is still not a well established and documented process.Build outputs(e.g.Docker images)are continuously scanned for secrets.Production secrets are monitored,and there is a remediation process in case of exposure or compromise.Developerenvironme
64、ntsDeveloperenvironmentsCI/CD pipelines&software artifactsCI/CD pipelines&software artifactsRuntime environmentsRuntime environmentsSource Control(Source code&Infra-as-Code)Source Control(Source code&Infra-as-Code)Moderate exposure riskLow exposure riskWhitepaper|Secrets Management Maturity Model21T
65、he ModelLEVEL 4 EXPERTSSecrets managementSecrets detectionSecrets are stored in a vault with access controls and logging.Dynamic secrets with limited scope are used for development when possible.Pipeline secrets are short-lived,scoped,and stored in an external vault.If possible,build secrets are rep
66、laced by OpenID Connect(OIDC)tokens for auth.Secrets are stored in a vault and loaded dynamically from a secrets manager.Restrictive access controls and logging are enforced.Blocking scanning is enforced for all branches(features,hotfix,etc.)in CI pipelines.Production secrets rotation is scheduled&a
67、utomated.No presence of valid hardcoded secrets in past or current revisions of source code.All repositories are continuously monitored and blocking scans(pre-receive)are setup.Remediation workflows are automated and fixing is handled by developers.Scanning before pushing code(pre-commit/pre-push)is
68、 adopted by all developers.Developers are systematically involved in the remediation process.DeveloperenvironmentsCI/CD pipelines&software artifactsRuntime environmentsSource Control(Source code&Infra-as-Code)Limited exposure riskWhitepaper|Secrets Management Maturity Model22The ModelBonus:Kubernete
69、sAs more and more organizations are making the shift to cloud-native technologies,Kubernetes has become the de facto choice to orchestrate container-based applications.Thats why we decided to give it its own place as a bonus in the Matrix,allowing us to be more specific about this unique technology.
70、Out of the box,Kubernetes supports Secrets objects to store sensitive information like passwords,tokens,SSH keys,etc.securely.This construct eliminates the need for hard-coding sensitive data in the application code but needs to be handled with extreme caution.Level 0Secrets are hardcoded in manifes
71、t.Level 1Secrets are stored in a Kubernetes Secrets Object.Level 2Secrets are loaded from external vault.Level 3Secrets are loaded directly into the pods.Pods share the same credentials.Level 4Secrets are ephemeral and each pod has its own set of secrets.Other considerations 06Whitepaper|Secrets Man
72、agement Maturity Model24Other considerationsLike any security topic,secrets management does not exist in isolation.To conduct a thorough security posture analysis,it is important to consider related domains.The ones we have listed here have been deliberately excluded from the matrix since we conside
73、r that they go beyond the strict framework of secrets management.However,this does not mean that they are optional:on the contrary,they require an equally important consideration.In other words,if you want to put effort into improving secrets management policies,you cannot overlook the following:Acc
74、ess controls are used to answer the question:who has access to what and when?It is obvious that nothing can be secret if it can be read or updated by anyone.Engineers should not have access to all secrets in the secrets management system,so the least privilege principle should serve as a guide to pr
75、ogress in maturity.Our matrix does talk about the scope of the secrets at different levels:the secret management system needs to provide the ability to configure fine granular access controls on each object and component to accomplish the least privilege-required principle.Yet well-implemented acces
76、s controls are a much bigger cybersecurity topic(including Identity and Access Management)that we do not have the vocation to cover in all its subtleties.The security of a secret depends,among other things,on its basic qualities:if the secret can be any character string chosen by a human,chances are
77、 that it will be easily cracked by brute force or a dictionary-like attack.On the other side of the spectrum,the most secure secrets are generated by high entropy hardware random number generators included in specialized HSMs.They would probably be too costly to implement&operate for most use cases.
78、Furthermore,having high entropy secrets is great,but useless if theyre stored in cleartext in a database.Choosing high entropy secrets,the right hashing&encryption algorithms for your secrets at rest&in transit is another important part of any secrets management policy.Access controlsCryptographic&e
79、ncryption qualityWhitepaper|Secrets Management Maturity Model25Other considerationsLogging is an integral part of maintaining an organizations security posture,and this is also true for monitoring secrets.You should be able to know who requested a secret and for what system and role,when it was used
80、 and by which source,when it expired etc.Authentication and authorization errors are also a valuable source of security information.Having auditing tools and processes is definitely something to expect from a mature secrets management system.Logging and auditingSummary07Whitepaper|Secrets Management
81、 Maturity Model27SummarySecrets management has a considerable impact on the security posture of organizations.With the advent of DevOps,the amount of sensitive information in use in software factories has exploded,creating a gap between theory and practice:in theory,all the“crown jewels”are closely
82、guarded within a vault and scrupulously respect the principle of least privilege.In practice,teams continue to generate large quantities of secrets as they scale services and infrastructures,bypassing outdated controls.Secrets are easily exposed,sometimes without anyone noticing.This is a difficult
83、problem to solve,even with all the flexibility automation brings us.Thats why some organizations do not invest sufficient time&effort into it despite the percentage of security breaches originating from exposed secrets.Reducing this attack surface requires the right controls to be placed along the D
84、evOps cycle,and to encourage collaboration between developers,security engineers,and operations.Not taking into account the human factor in the management of secrets would be a serious mistake.No matter the technology,leaks will happen.The response lies at the intersection of people,tools,and proces
85、ses.Having a plan to be notified as early as possible when a leak happens and to face incidents with peace of mind is a must.We hope that our maturity model will be useful to allow you to take stock of the actual state of secrets management in your organization,and more importantly,what are the step
86、s to improve it.About GitGuardian08Whitepaper|Secrets Management Maturity Model29About GitGuardianGitGuardian,founded in 2017 by Jrmy Thomas and Eric Fourrier,has rapidly emerged as the leader in automated secrets detection and is now focused on providing a comprehensive code security platform.The c
87、ompany has raised a$56M total investment to date from Eurazeo,Sapphire,Balderton,and notable tech entrepreneurs like Scott Chacon,co-founder of GitHub,and Solomon Hykes,co-founder of Docker.GitGuardian helps software-driven organizations strengthen their overall security posture and comply with appl
88、ication security frameworks and standards by reducing the risks of secrets exposure across the SDLC.With GitGuardians policy engine,security teams can monitor and enforce rules across all their VCS,DevOps tools,and infrastructure-as-code configurations.With more than 210k installs,GitGuardian is by
89、far the n1 security application on the GitHub Marketplace.Its enterprise-grade features enable AppSec and Development teams to deliver secret-free code in a truly collaborative manner.By pulling developers closer to the remediation process,organizations can achieve shorter fix times.Its detection en
90、gine is trained against more than a billion public GitHub commits every year,and it covers 350+types of secrets such as API keys,database connection strings,private keys,certificates,and more.Learn more about GitGuardian:GitGuardian-WebsiteGitGuardian-Internal Monitoring-GitHub MarketplaceState of Secrets SprawlGitGuardian monitors every step of the 2022 GitGuardian.All Rights Reserved.