81

My advice would be to remove the secrets from the drop-box and store them elsewhere. Your instructions have to be easily human readable by anyone, but they can include instructions on how to get access to the properly secured part of the data. That lets you separate the accessibility side of things from the security side. Once you can think about security ...


74

Get a USB device. Put all secrets on the USB, preferably in a KeePass file. In the documentation, tell the new person where the USB is and how to unlock it, but put the device in a secure physical location like the owner's office, the company safe, a secure deposit box, etc. Somewhere out of the reach of the public, and away from the prying eyes of other ...


60

High Level Culture In my experience, shifting a security culture takes 3 steps: Get management buy-in to do things differently Get personal management engagement to lead the way on what is important Set the tone through training, media, and in-person events that "people like us do things like this" Here's the thing: management has to be leading the charge ...


39

You would never ignore a threat, and perhaps that is semantics over your wording. You either accept, mitigate, or outsource the risk for the given threat. In this case, that would be: accept that there will be a $X loss, mitigate fix DRM or find DRM alternate to protect the product, or outsource using insurance or place the risk on someone else in the same ...


32

Think of your users as customers. You are helping them meet their business requirements to secure data. That means it's your job to keep the requirements placed on them as sensible, justified and limited as possible. It's UX engineering. Examples: if you make it hard to get a proper login on a system, workgroups will share passwords on post-its or ...


29

Create 'emergency use only' accounts For most systems, you will have some kind of privileged accounts that are used in their everyday administration, those may or may not be personalized depending on your organization policy. As for any credentials, you may lose access to them for various reasons - either by the person knowing them getting hit by a bus, or ...


26

He is the Data Owner. Not you. If you get hit by a bus, he will need access. You should absolutely give him access. This request is not a surprise at all. If you built a website for me, I'd ask the same. BUT, and this is the important part, you also cannot be competing with him for the administration of the database. You are the administrator, not him. He ...


15

If you want an analogy, read this. As for the list of vulnerabilities: Emails can be sniffed in transit, since they are not encrypted (some sites will opportunistically employ encryption for transit, but this is not reliably activated). Emails will be stored on physical disks in the servers which are involved in the operation: the sender's email server, ...


14

TL;DR: NO (but we should define what "ignoring" means; from the text of the question I suspect we're actually of the same opinion). You do not "ignore" a threat. The ancient saw says that you do not fear a threat that you cannot avoid - stultum est timere quod vitare non potes, since fear will avail you nothing. But few threats are completely unavoidable ...


13

This is a really difficult issue, but if you have the chance to change things, you should give it all you've got. You can't change a culture overnight. However, there are steps you can take to begin changing the culture for the better. Policy enforcement This is first on my list. I'm in full agreement here that you need to enforce security policies, and ...


11

Maybe a better solution to your situation is to design the system such that even if you are hit by a bus, and your credentials are lost forever, nothing bad happens. Perhaps it's best to think of the problem as two problems, authentication and authorization. Authentication establishes that you are who you claim to be. Some system can know that a request it ...


10

There are four basic strategies to control risks: Avoidance: Applying safeguards that eliminate or reduce the remaining uncontrolled risks for the vulnerability Transference: Shifting the risk to other areas or to outside entities Mitigation: Reducing the impact if the vulnerability is exploited Acceptance: Understanding the consequences and accepting the ...


9

The simple and deepest answer is that SMTP (Simple Mail Tranfer Protocol), which handles the sending of mail from client to mail server and between mail servers (other protocols such as POP3 and IMAP are typically used to retrieve mail nowadays), was originally designed for use in the ARPANET, which operated in a time when anyone who could use it had a ...


8

Your questions is about preventing the inclusion of hardware that contains intentionaly created backdoors, but I suggest that in addition to prevention you consider detection, mitigation, and response. There are different levels of sophistication in creating and detecting hardware backdoors. So, in part you need to understand your own level of expertise in ...


7

This is a really broad question that does not have a single answer. Some categories of challenges and risks include: Reduced control. The corporation has to take whatever devices the employees select, and loses control over them. The corporation may also have reduced leverage to control the software on those devices. Dependence. The corporation becomes ...


6

Most of the answers here relate to the handling of credentials, probably due to this explicit question in the OP: What's the best way to manage the "secrets" (passwords, private keys, MFA access) in this documentation to ensure it remains comprehensive without compromising security? However, the title asks a different question, which I don't see ...


6

First check with your legal expert if there are any laws in your country which require you to have a minimum retention period. For instance depending on your industry you might have to take into account either of these regulations: Sarbanes-Oxley regulations: To comply with SOX guidelines, companies must retain auditable emails for a minimum of five years ...


6

Been in this position a million times. Just explain that he could inadvertently break something if he's not careful and give him the logins as he does own it. Make sure to do a db dump before so you can restore if he does break it (for a fee of course).


5

My first observation is that security is everybody's responsibility. No one person is going to be able to police an entire organization's codebase. Security design and enterprise design are inherently different in purpose and goal, but the two should interact closely for best result. An enterprise architect's goal is to design a system that meets business ...


5

PCI-DSS is not enforced by any government; compliance is a requirement for handling credit card transactions in any way. Fines and exclusion from processing are two enforcement actions that can be taken. I'm not sure exactly who can definitively do what but the card brands, the acquiring banks, and the processors are the entities usually involved in either ...


5

I'll take little detour and answer the question implied by this part: but they simply don't care @shroeder's answer already covers the starting point which is to have the management on your side. And teaching people how to secure themselves is a very good take on how to perform the indoctrination, but I'll extend it. Let's ask how you can motivate the ...


5

"OK, we can't achieve this standard, so let's look for a standard that we can achieve without much work" is pretty much the opposite of a security-aware organization's mindset, though I'd agree (after 5 min of lecture) with the presumption that 27001 might be a bit much work – but then you'll have to just live without that certification. Instead of trying ...


5

This sounds like a great application for threat modeling as part of the design process. If you’re unfamiliar, threat modeling is a technique involving the creation of threat landscapes, where a product/service/system is analyzed to find potential risks. Fundamentally, threat models are simply conceptual decompositions addressing potential threats, so they ...


5

Every business, no matter what it does or how big it is, runs on information Information has value to the business, so the business needs to protect the availability and integrity of that information Information has value to others; your customers, your employees, your business partners, and has value to others who can exploit it for their own gain, so that ...


4

One of the main reasons I don't like using e-mail for transporting any sensitive information is simply because once the e-mail with sensitive information has left your organization, you've instantly lost any control you may have had over it. For example User has sensitive e-mails in their inbox, just sitting there. If account is compromised you now have ...


4

One risk of BYOD is the idea that it reduces sysadmin and helpdesk costs. It is a myth but it can damage productivity a lot. With BYOD, the users themselves take charge of inventory and replacement of failed parts. But they still need to connect to the internal network and be helped with the corporate applications (i.e. intranet Web site), and since the ...


4

To post a contrary view to AJ's excellent answer: At a large corporation, architecture may end up being the responsibility of multiple teams in different departments, countries, regions etc. in order to be performant for each region, whereas enterprise security is likely to be managed from a global perspective to reduce risk to the organisation as a whole. ...


4

Sensitivity of data is determined by the data owner who is responsible for classifying the information and also liable in case the information gets compromised. So no matter if data is used by human resources department or marketing, the classification will stay the same. The relevant metric for estimating the sensitivity is closely related to the cost of ...


4

I think the question is too broad so I will only cover what I think is the main aspect: Is security, at the end of the day, simply risk management? That's what it is. There are several risks relevant to SMB which are addressed by information security, for example: Ransomware might result in the inability to access data or systems which are critical for ...


3

Of the ISO 27000 range of documents, only 27001 is a certifiable standard. The others in the range are guidance and advisory documents. The first step of ISO 27001 implementation is defining the scope. In my experience it would be unusual to have "IT Processes" as a scope - it's usually defined by business area. So for example the Operations part of the ...


Only top voted, non community-wiki answers of a minimum length are eligible