![]() ![]() One way to combat this is to encourage staff to keep a "Things Only I Do" list and review it occasionally to evaluate opportunities to train other team members on the basics. It can be hard to remember all the buttons and switches you are responsible for when you've done them so long they've become automatic. Solution: List your responsibilities, and regularly practice offboarding them. In a company that has a very low rate of turnover it's likely another story. In a company that onboards and offboards frequently, you may have many strategies to deal with all those little gotchas. Maybe it's something as trivial as that they owned the calendar meeting invite and now you can't make changes or cancelations without spinning up a whole new event. Maybe the departing employee is the only person who knew how to run the test to verify cert pinning. Maybe an admin account's credentials left along with said admin. Problem: Offboarding an employee who has moved on is one of the most common times to discover your organization has a single point of failure. Let's walk through a couple of hypotheticals and highlight ways you might turn them into user stories to audit your organization for single points of failure. On a more in-depth level, many products (such as Inclave, on our end) work to give users a secure way to recover a team after access has been lost. This can be done in as simple a way as setting up a password manager for admin keys so that if an employee leaves the company, the password manager account can be passed on to their successor. This is why our products make use of distributed ledger (or blockchain) technology.Īnother way to lessen the stress of a keeper-of-the-keys scenario without compromising on security would be to build in internal ways of reclaiming keys. Distributed authority is one way to make sure that loss of information in one area does not result in all data being lost, as well as guaranteeing that your software's authority structure mirrors your real-world authority structure. Losing those individuals, or those individuals losing those keys can be disastrous. Security policies often require that only select individuals act as the keepers of the keys. If you are unable to restructure your organization to allow interdisciplinary work groups, consider holding periodical same-paging meetings to ensure that information is flowing freely through your organization. As a bonus, cross-disciplinary work groups have been found to have a whole host of benefits related to increased communication and trust as well as driving results. In this way, we hope to avoid situations where personnel find out about changes only after they've happened. We use these meetings to unblock tasks as well as to make sure that the scope and impact of changes is understood at all levels and in all departments. SpiderOak has weekly squad meetings where cross-disciplinary and cross-departmental squad members meet and discuss ongoing changes, questions, and concerns. In these cases, interdisciplinary work groups are your best bet at reducing conflict. Perhaps only your customer relations team knows that a certain customer's contract means a legacy operating system needs to remain supported. Maybe only your backend developers understand that a change will break compatibility. Sometimes specialized information gets stuck in a single department or section of a product. Suddenly they're out sick and you realize you don't have anyone else with access to update the release notes. Long term employees are sometimes inadvertent single points of failure: tribal knowledge and simple consistency can obscure an individual's responsibilities. Or, maybe your staff is small and there simply aren't enough hands available to make sure every task has at least two people who are comfortable with it. For example, your security policy may necessitate a Keeper of the Keys situation that prevents you from distributing authority. There are any number of reasons you may find your organization at risk of having only one person with the access or knowledge required for a given task. Systemic causes of single points of failure ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |