Given the millions of payment transactions we process every day at BJ’s Wholesale, as well as innovations like EMV chip technology, security and fraud prevention continue to be top-of-mind issues. The good news is, over the past few years, our IT Security group has received a lot more support from our business units. Some areas include credit card protection and technologies such as Point to Point encryption.
In assessing risk, we look at where it makes sense to mitigate risks instead of moving forward with vendors that do have the controls in place. As much as a business can come forward with a vendor or product they really want to implement, once the due diligence process is complete, everyone may not be comfortable with that solution, so we look to other vendors.
It is also critical to strike the right balance between application usability and security controls. There is always a lot of discussion and conversation there. A few examples:
- Something as basic as password policy can become an issue — how many digits a password is, what the complexity is, or how often it gets changed. Are your users frustrated with the experience? Are the policies the same for mobile apps?
- Other elements of login have to be managed as well. If an application is accessing data that isn’t highly sensitive, sending alerts or doing something else very basic, we may not need to manage that process as tightly as one for a highly secured application. But we do need a simple self-service password reset function so we’re not overburdening the help desk.
Making security an all-in effort
It’s important to remember that security exists on a gradient. It’s not usually a black or white thing, so applying check-box controls as a gut reaction is rarely a good idea. Applying every control in the book may keep everything watertight, but it may not be needed, depending on the risk, and may have an impact on application usability, cost and performance.
The best antidote to rigid security thinking is education. As an enterprise architect, I look at my role as a mediator and a catalyst in the process. Enterprise architects shouldn’t take sides with security or with the application owners or anyone, really. They should try to come in and provide different and broader perspectives on things. If a lot of fear and uncertainty is going around about cloud security architecture, for example, our role is to bring in some rational thinking around the issue and balance both sides to specifically show how security could be implemented to meet our needs without hindering the agility a cloud platform can provide. If one side is too far along on the right or left we should bring it back into the center.
And if something gets stalled in risk review, we should be a catalyst to move it forward and provide evidence of how other companies have worked through it. Then we provide the background architecture to say, "Here is how we could do it, knowing what we know about our own organization and the applications we have and how the infrastructure needs to fit together. And here are a couple of approaches we could take to actually take steps going forward."
Approaches like this make cyber-risk feel like it’s a shared effort. We have standard processes for risk assessment as well as a subcommittee that includes our CSO and other top executives and focuses on reviewing security issues that are escalated to them. We have Finance involved as a sponsor in initiatives around protection of payments information. And we increasingly partner with the business to ensure that risk prevention doesn’t become revenue prevention. The last thing you want today is for security to be an, "IT, go and implement this" effort. For information security programs to really succeed today, it’s got to be an all-in approach and a way of life.
