Digital Identity Insights: PKI Implementation Best Practices

welcome to today's webinar PKI implementation management best practices I'd like to extend a warm welcome to those joining in the first of our monthly webinar sessions and say welcome back to those who attended multiple sessions in the past today's evolving cyber security landscape demands the high assurance scalability and security of digital certificates issued from a trusted public key infrastructure to successfully secure enterprises however an effective PTI can be difficult to implement and manage without knowledgeable and dedicated resources in-house although attempting a deployment on your own sounds appealing and more cost effective the key to a successful TTI implementation is fully understanding the entirety of the project before beginning by outlining each critical task upfront it's easy to quickly realize the importance of enlisting dedicated resources to assist the entire process from day one today's webinar agenda by certified security solutions a leading cyber security company that builds and supports platforms to enable secure commerce for global businesses connected to the Internet your expert today is Michael Thomas as the director of delivery at CSS Michael Thomas is responsible for overseeing and managing engagements between CSS and clients previously Michael was responsible for managing projects and programs at organizations in the financial banking and insurance industries everyone please join me in welcoming Michael Michael the floor is yours thank you Sarah as Sarah mentioned we're going to move away a little bit today from the usual technical conversations a PKI and we're actually going to talk about the operational aspects of PKI in particular I want to dive a little bit further into an implementation of a PKI and your organization and what I want to talk about is how do you prepare for a project of a PKI implementation what a projects going to look like and then what will happen after the project's complete and the project team goes away we'll also touch on why you may want to look at using external expertise versus just keeping it completely in-house and then we'll summarize the presentation and focus on a few the key takeaways to start let's talk a little bit about why PKI is becoming more commonplace in the corporate infrastructure I would say that probably the two main drivers of increase in PKI especially on-premise PKI implementations is first is the changing landscape but bring your own device inside an organization organizations now really want to move away from giving corporate assets to FTE and also FTE use wireless devices now to access email access corporate assets of applications of different types and so therefore they need to be secured also the Internet of Things is becoming a very hot topic most people have heard about Internet of Things and it's creating a very large device boom IOT devices don't have a traditional user interface there isn't usually a place where somebody can go and just log on but they still need to connect to a central location securely so with that digital certificates are a great way to be able to satisfy that need so in preparation for a PKI implementation the first thing a project manager or a manager that will oversee this is that the PKI is going to have two distinct divisions of deliverable ownership I call it the two-headed Hydra the first piece is going to be a security team and those usually report up to the C ISO this security team is going to be tasked with creating a certificate policy and defining the certification practices the certificate policy is going to generally be about the what of the PKI in other words what types of certificates are going to be used and what will they be used for what's the level of trust the PKI has the practices is going to define more how do we satisfy the what of the certificate policy and it's going to become the cornerstone or one of the pieces that will be required when the network operations team comes into play usually these teams report up to a CIO and they're going to need to build and design a PKI that adheres to the policies and practices set forth from the security team if it's not executed properly the assurance level of a PKI can be compromised we'll talk a little bit more about assurance levels and trust of the PKI in just a couple minutes some of the other things that you need to really think about is the appropriate skill level in your organization and the their availability the field of PKI experts is waning and it's becoming harder to attain and retain that talent more so PKI experts inside an organization or somebody who has the expertise has other duties that they are tasked with doing and maybe not be able to fully focus on putting together a PKI implementation and following the activities and tasks to be able to complete it successfully also there needs to be an extreme sensitivity to these policies and practice a PKI is based on the trust that is put into it and must be configured with that in mind there are certain pieces within a PKI during the implementation process that will live with that PKI throughout its life style life cycle if not defined and delineated during this implementation practice you could actually end up creating a PKI that is invalid from its inception so let's say that we have our PKI project we're now ready to begin we have our resources to find we have all the pieces put into place so how do we start it's a great question and it's understanding what goes into your design the design is the very first piece that we're going to make with PKI and it's going to have multiple pieces that get put together to make it a successful implementation and the very first piece is a use case use cases for project managers is very common it's for most projects it's one of the first steps that you have to go through in a PKI the use cases will be what is the PKI going to be used for now and in the near future and the reason why I call this out specifically in this project is because use cases for a PKI can live in multiple different locations it will not be just within the technology infrastructure department code-signing for developers may be a use case that's in your organization there also may be ssl certificates that are put on iis servers that need to be accounted for also as with the internet of things coming more and more prevalent the business unit may be coming back to ask about handheld scanners or different devices that need to have certificates put on them so therefore they can talk back to an ERP application or some other accounting function assurance level what will these certificates be used to protect this becomes a very important question at the very beginning of a project and what we're asking here is if a certificate is only used for let's say ssl signing or code signing doesn't have a high importance then an assurance level or a trust level of PKI may not need to be as high as maybe a PKI that is you used for documents signing or may be used for validating securities trades something that has a much much higher financial impact and a much greater risk in in the organization operational processes is there a current process in place for certificate lifecycle management there are many organizations who have a PKI and the PGI is degradation x' we need to take a look at those operational processes we need to go back and find out what exactly happened and what can we do to rectify the situation many times projects and PKI inside an enterprise will put themselves into a position where maybe the tasks were too much or maybe they were not enough even to necessarily sustain an assurance level of the PKI so we need to look at those operational processes and make sure they're sufficient we need to also make sure that we have a uniform policies and practices statement there's that word those words again policy needs to be clear it needs to be concise the reason why is because any kind of audit that goes that is done that has the PKI involved and for example PCI audits Newark audits for energy sectors these statements these policies will be used as the cornerstone of the audit the first thing an auditor is going to come and ask is what what was deemed as the policy what were the practices that were identified what was claimed to be and then right behind that they're going to ask were they followed were they executed throughout the lifecycle of the PKI also we need to plan an account for the route signing ceremony I'm going to stop here for a minute and press down on this specific point a route signing ceremony is probably one of the most employees the most important this is your Keystone of your PKI project reason why I say that is because a root CA is akin to the master key to your entire PKI if compromised at any point in time throughout its life from its creation all the way to the deprecation of a PKI that vulnerability can be exploited and that vulnerability could expose your PKI to malfeasance it is very important that when this route signing ceremony is planned that it is done with a very very specific goal in mind to keep a chain of command with that route CA also we want to make sure that the PKI components are properly operationalized again when we get into steady-state of the PKI we want to make sure that we know who is responsible how are they responsible and who how many people need to be present for certain operations especially with the route PK with the route see a certain there should never be a time where only one person can get into a root CA and do specific functions reason being is if they are the malicious actor they then have the master key and they are the ones that could be able to create a vulnerability so the question that most people ask right out of the gate is so how long is this going to take what is this going to look like and what's my timeline so the short answer is it's going to be about an eight week project now that being said obviously with different organizations different change management processes and different preparation steps this timeline can expand and possibly contract but in this grid this shows a general overview of what a PKI implementation project will entail in your first week you're going to go through a kickoff in design sessions again use cases use cases use cases need to make sure that we get those all defined this is going to help you understand what types of certificates your assurance level how many tiers a PK I may have a PK I will have at least two tiers and could have many tiers depending on the uses and the functionality of the PKI during the second week we'll get into drafting the first iteration of the design and as that draft is coming to life the certificate policies and the certificate practices are being defined these different tasks run hand-in-hand throughout the second second and third week as things become more clear as different practices are put together and identified or defined the design may change and it may have specific impacts on your hardware that you're going to use for a PKI for example a higher assurance PK I must have at least hardware security modules or HSMs at the root level and sometimes we'll even have them at the next tier down which would be the subordinate CA level so all of these different pieces that come together need to be attended to and validated as you go through the first three weeks of the project week four is mainly getting ready for a the root key signing ceremony again this Ricky signing ceremony is going to have a very scripted event sequence to it it will have a document that should have every single step for a route signing defined to a point where an auditor will actually be able to sit in the back of the room and tick through each individual step of a route signing the route signing ceremony must take place in a controlled location it should not take place in the cube in somebody's desk it should actually take place in a in an area where the amount of people or the amount of interference is controlled for a very high assurance PKI this event may be filmed may also require cell phones be put to the side and no other external computers in in the area at the time it is extremely important that the chain of command as a root CA is brought to life is preserved root CA cannot be left alone even during a route signing ceremony it must always be in control of somebody and as the root CA we complete the route signing ceremony it must have a place to go and reside that follows the certificate policies and the certification practices that have been set forth in the documents if this is compromised this root CA could be considered to be invalid and therefore every other step on the PKI implementation would be considered invalid as a project manager I usually look at the route signing ceremony as being my starting point I will work back from that route signing ceremony and establish all the other activities and tasks knowing that they need to work up to that moment and all subsequent activities would then stem from that route signing ceremony also some things to consider that there will be some disaster recovery you're probably going to need to take a backup it is very common to have two routes EAS one as a primary one as a backup again both need to follow the chain same chain of custody throughout their lifecycle if shipping a root CA and it has HSM hardware's and hardware and cards it'll be very important to figure out a sequence of events so never can those three items be pulled together in one location for a period of time out of the control of trusted advisors when we get into week six we start talking about actually issuing certificates we will then make sure that the certificates that are issued or valid it is never a good practice with a PKI to perform what we would call a big bang in other words just turning on the PKI and letting certificates float we need to make sure that it's controlled to make sure that there is a small subset or a small pilot group that is started and then we validate the certificates with that control group and then start opening it up to the larger audience all as this week five and week six go will validate the health of the PKI and there's some very quick steps of just validating that the PKI is up that's running its issuing certificates all the CRL is in place are in place all the CDP's are in place and that any application is actually able to use the new PKI and function with it this migration and validation strategy usually takes about two weeks when we get to week eight the project will actually begin wrapping up the first item that I've put on here is completing of documentation and the you might have as well what documentation this goes back to the point that I made at the beginning we're going to have to turn this over to an operational team there's going to be maybe approvals that certain people need to understand how they approve a certificate request there will be auto enrolment people need to understand how to check to make sure that that auto enrolment is working and also not just creating certificate after certificate because of some sort of problem we have seen with shot 2pk is and using Windows XP where Windows XP would continually ask for a new certificate creating a problem because there were twenty or thirty thousand invalid certificates now created that needed to be that needed to be remediated so when we get to the end of week eight we're going to move the PKI into a steady state and we're going to start assigning ownership to these tasks also one thing to consider is with any organization people will come people will go so when those roles change how does that change of ownership take place and how do we make sure that we don't let something fall between the cracks this is especially important when we talk about HSMs hardware security modules and the cards that go with them many times organizations will have people leave the organization they will take their card with them and they will take their passphrase with them without any kind of transition what that hat what happens then is organizations get to a point where they can't have a quorum of different users to be able to perform a function on the root CA that again could create a vulnerability with the PKI and make it invalid and actually can create an outage within your network so in creating this slide I noticed immediately that it looks like these are linear events that you do this on week one you do that on week two so on and so forth so I inserted this slide into this to show some of the overlap from a Gantt chart and again when going through the kick off in requirements many different points that are taken off taken away from those requirement sessions will actually go into building the CP and CPS and governance guidelines as that is taking place the design sessions and the design of the PKI will start forming at the end of the CP and cps document creation we will then have enough information and enough artifacts to be able to finish off the design now let me touch a little bit on a CP and CPS especially for high assurance PK eyes these documents could actually have to go through a legal review and in many organizations we do go through a legal review to note to build a PKI design you need to have the technical content agreed upon and signed off the actual legal review of a CP and CPS is does not have a dependency to the finalization of the design there could very well be a legal review that runs months after this entire project is complete so we are going to then move right into preparation for your key signing ceremony your design artifact should be complete as you start beginning your key signing ceremony the design needs to be complete so we understand how many HSMs are we going to use net HSMs for the subordinate CAS or are we just going to put HSMs on the root CA once we get our preparation complete then we'll be ready to start the root signing ceremony and the downstream installation and configurations of our subordinate CAS and the downstream applications downstream applications could be something like an end as server network device enrollment server rpki is installed and once the downstream applications are installed then we're ready to start with our deployment of a certificate or a set of certificates and then going through our final testing to make sure that the peaky eye is up running and healthy and finalizing them the operationalization of the PKI and moving into a steady-state so with an in-house PKI implementation versus an external what's the difference what would I get with using external expertise while using external expertise we'll help you with identifying your use cases and understanding the technical needs and one of the things that you're going to find very quickly with looking at your use cases is does this need an approval process is there some way that we can install an approval process a PKI expert are a consultant may be able to help you in understanding what is a lower-risk and can go through autorun role meant versus what kind of certificates really need to have an approval process and then also help you work through them for example making sure that a requester of a certificate isn't also the improver approver so they can do both they can provide guidance in deploying an effective PKI for your organization again this goes back to making sure that you understand what an HSM is how it can help you how you can build a quorum of cards so you can have the appropriate amount of people to perform functions on either the root or the subordinate CAS they will also guide you through the key signing ceremony to preserve that the chain of custody again this is the most important thing of a PKI in my eyes is that you must make sure that that root CA is never exposed out online and it also is never left at a place where it can become vulnerable help detail certificate template configuration there are certain information that will come with a certificate request inherently there's other information that's optional a PKI expert will help you understand what needs to be what is the bare-bones base amount of information that needs to be sent with a certificate request versus what can be added as the certificate is being created there's also different ways to create meta tags and what those meta what that metadata can do is enable you to track on certificates in a different way so maybe help you isolate exactly what that certificate was for or maybe even get to a point where you can understand what region that certificate came from and then there's also migration assistance again moving from one PKI to another there's different tips and tricks and different ways that you can go about to make sure that as this new certificate is issued off the new PKI and the old one is either expired or revoked that you can track on that to make sure that when the old PKI is actually turned off that you are not leaving an application or a some different divisions and alert so in concluding of this presentation I wanted to jump on some salient points that we're going to take away from this conversation the first is you have to define your PGI use cases it needs them you need to make sure that you understand what you want in the current PKI demands also in the near-future PKI demands you want to make sure that you're not building something for today and it's not going to accommodate tomorrow we need to build policies and practices before completing the design the policies are so important because that will tell you and an auditor what you said this PKI was going to be set forth to do and also the practices will tell an auditor or internal or external how you were planning to satisfy those policies this will come back again and again even for PKI health checks from an external party this is the basis of that conversation creative design that will accommodate the current near fused future certificate requirements prepare for all aspects of the route signing ceremony we talked in depth a little bit about that there's plenty more that could be talked about I could probably do an entire webinar about a route signing ceremony and how it needs to be scripted we can then complete the route signing ceremony and then configure our subordinate CAS and then we install the downstream applications then once we start utilizing the PKI we operationalize the PKI and make sure that all the aspects of the PGI and keeping it healthy are are satisfied what a CSS offer and the PKI engagements we offer a readiness assessment that readiness assessment actually will we will sit down with you and help you define within your organization what those different stakeholders are what they would be responsible for for a PKI and how you would maybe operationalize your PKI after a project is complete PKI health check we can go in and help you understand if your PKI is healthy and it does live up to the assurance of levels that you are claiming it to be PKI design and deployment is self-explanatory managed service so sometimes in a company maybe it's not big enough to necessarily have the required expertise or the sets of skills that are needed to bring bring on maintain implement and maintain a PKI a managed service what that what we would do is then take the responsibility of building and implementing a PKI and then putting either a gay way or subordinates EAS on-site on your premises so therefore you don't have to worry about the integrity of your route CA you don't have to worry about creating and performing those functions on a quarterly yearly basis we would take that responsibility for you and just allow you to be able to create your templates and use the certificates for whatever your business solutions require and then certificate management system is an operations management platform this is an in-house application that we would use to help you in operationalizing your PGI in other words being able to help you build your workflow your operational workflow being able to help you understand what certificates have been issued if your CR ELLs are stale and are about ready to expire and assist you with actually enrollment of certain types of certificates so that concludes my presentation today I thank everyone for taking a moment to listen and get a little bit more depth on a PKI project at this point I am going to open it for questions and answers sure Thank You Michael so much for the insights really appreciate the content I do have a couple questions I do believe this question was in regards to the project planning slide but the question is should routes a servers and subordinates these physical servers or can they be virtual great question a root CA should always be a physical server and it should actually be never have touched a network a root CA again is your master key and putting that master key out onto a network actually could create a vulnerability malware could be installed somebody could hack into it for the subordinate CAS they actually can be virtual servers or physical servers whatever you know your organization prefers there really isn't a preference either way on the subordinates okay thank you nice questions that we have in the queue is what are some of the most common DIY PK implementation errors that you see on a regular basis so the most common do-it-yourself pki implementation errors I would say run with not giving enough attention and credence to the certificate policy in the certification practice statements and what I mean by that is in some organizations the policies will be created in such a way that they are absolutely arduous to maintain and carry out and so therefore organizations then aren't able to follow their own policies and practices to be able to keep a healthy PK i excuse me the other side of it is if there is no policy and practices statements and leading back to the last question we have seen that do-it-yourself in-house implementations the root CA was actually a virtual server the the creator of that root CA would say well it's never really been online but if it's a virtual server it has technically been a part of a network so those that would be probably the largest error that we've seen other smaller errors usually can be remediated especially during a health check and they run in the realm of opera opera opera it I can't say it anymore operationalizing your PKI and having the appropriate workflows in place to be able to issue certificates okay great and this one you may have touched on this a little bit but is it important to have an intermediate see a server or is it optional it is optional and actually that is a great question so as I had said peaky eyes are usually two-tier and top tier being the root CA and then the subordinate CAS there are different use cases and there are different circumstances where it's absolutely needed to have an intermediate tier those are that needs to be scrutinized on a case-by-case basis and a PKI expert can most definitely give you some insight on what those use cases are and why you need to do that another question we have once a PKI project is complete what are some of the things we need to do to continually keep our PKI healthy great question so one of the very first things is crl upkeep and maintenance you're going to define a crl window for your both your roots a out to your subordinate CAS certain CRLs by the way our certificate revocation lists and so therefore to keep your PKI healthy you're going to need to make sure that you have those practices in places that so that the CRLs remain fresh and that they are republished during the overlap period other things that need to happen are the root CA needs to make needs to follow the chain of custody throughout its lifetime again you can't leave it in a in a desk drawer locked if your certificate policy says that it needs to be in a safe if there is a need for multiple people to be able to do certain tasks within the PKI that those practices are carried out and again I want to touch upon that if you use HSMs as you go through turnover within your organization that there is a valid process in place to transfer that authority with the cards okay another question we have here you mentioned some increased PTI usage recently and can you elaborate a little bit more on the driving forces that are leading to more increased GTI usage today oh absolutely so some of the things that we're seeing now on the horizon is VMware uses the new version of VMware actually uses certificates on on its within its application so therefore you need to create a certificate to be able to to execute on that also even for you know bring your own devices wireless devices we've seen a lot of people pull in now Cisco ice and some of the other mobile device managers into an organization those need to issue certificates we've also seen things kind of one-off things but Bluecoat actually uses certificates Bluecoat is a way for a proxy firewall within an organization and it allows you to monitor net internet traffic that comes out through the organization one of the best use cases i've seen as of lately is actually using direct access and moving away from VPN and what direct access allows a user to do is to be able to have their machine authenticate into your into the your office network without actually having to log into a VPN tunnel it's very convenient especially for salespeople and things of that nature that may want to have that greater convenience and are on the road all the time

Channel: Keyfactor

Views: 2,077

Rating: 4.7142859 out of 5

Keywords: PKI, Public Key Infrastructure, PKI Best Practices, PKI Help, cyber security, IoT

Id: SeouvN1N7FM

Length: 39min 18sec (2358 seconds)

Published: Wed Oct 26 2016