这是一个创建于 1944 天前的主题，其中的信息可能已经有所发展或是发生改变。
“活动页面一定要在七夕当天上线。”
“活动已经安排好，页面按照计划在制作，准时上线没问题。”
“业务系统更改需要经过我们安全部门测试才可以上线。”
“这个活动页面是有时效性的，七夕当天必须要上线，安全测试完，活动都结束了，先上线再说，不然，活动期间业绩完不成。”
“我们发出去的 1 千个优惠券，怎么一下子就被抢光了，而且，我们真正的用户都反应说没抢到。”
“又是羊毛党，页面有个漏洞可以批量刷优惠券，用户现在说我们耍猴，优惠券根本抢不到。”
“安全部门请解释一下。”
安全部门：“我太难了......”
上述情景在很多企业会遇到，企业都是以业绩为主，业务部门是赚钱的部门，安全部门是烧钱的。除了大型电商公司外，企业一般以业务部门的要求，优先考虑，安全工作要在不影响业务部门正常运转的情况下开展。如何在保证业务的同时做好安全，是企业安全建设需要考虑的重要环节。
一、制定安全工作方针
凡事预则立，不预则废，安全部门首先要做的，是制定一份安全工作方针，方针中除了整体安全建设外，还应包括业务部门和安全部门配合工作部分：
1 ）安全部门会拟定安全工作流程，包括安全测试、基线加固、补丁更新等，列举每项工作需要业务部门配合的部分、对业务运行可能造成的影响，流程与业务部门确定，达成一致，如：系统上线前、迭代更新前，需要预留充分的安全检测时间给安全部门。具体测试时长，收集业务部门、安全测试人员要求后由领导决定。
2 ）业务部门应该配置完善的灰度测试环境，保证灰度、真实环境一模一样。
3 ）业务系统升级迭代工作计划，需要安全部门派人参与，避免设计阶段带来安全隐患，如：尽量减少互联网暴露面，减少漏洞较多的中间件、框架的使用。
4 ）资产变更情况及时与安全部门同步，包括新资产下线，旧资产废弃等，保证安全部门日常检测的资产是全面的。
二、两者之间的平衡
用户交互性较高的系统，很难既做到安全又不影响用户体验，举个栗子：某网银系统没有验证码，安全部门判断存在暴力破解的风险，业务部门认为，每次都要输入验证码，会影响用户体验。这时候需要平衡业务与安全，做个取舍，安全部门需要列举不同场景下存在的风险，业务部门列举同场景下用户体验的影响，由老板做取舍。
同时，安全部门也需要从业务的角度出发，输出对业务系统影响最小又保证安全的方案，老板希望能解决问题的下属多过只知道抛出问题的下属。
类似的方案包括：
1 ） 前几次输入不需要验证码，输入次数过多，才需要输入验证码。
2 ） 业务逻辑漏洞容易被羊毛党利用，造成严重的经济损失，修复可以采用 session 机制等方式，跟进每个用户的状态。
3 ） 建立完善的风控系统，遏制羊毛党，不影响真正、优质用户使用系统。
4 ） 不易修复的漏洞，如果上线时间紧的话，先输出紧急抑制方案，如 Struts2 漏洞，先关闭相应的功能，临时修复。漏洞不能利用，业务不影响使用，后面再考虑升级框架。同时，网络中使用流量监控的方式，发现系统运行期间，互联网攻击行为。
5 ） 错误提示页面友好化，如：“您访问频率太快，请稍后访问。”等。
三、安全事件处理
攻防是个博弈的过程，没有一直胜利的将军，安全工作从来都是，平时看不到工作效果，出事了才知道安全的作用。安全事件也反应了前期安全工作中的疏漏，安全部门可以借助事件，推进之前没法推进的工作。如以下场景： 某单位业务系统，管理员经常映射高危端口到互联网，方便在家里远程办公，安全部门一直没法收集互联网开放的端口，以及弱口令控制。有一次单位中勒索病毒，大量服务器、数据库被加密。经查实是管理员映射 3389 端口到互联网，黑客破解口令进入服务器后，在内网大量散发勒索病毒。安全部门借此事件，向单位发布安全生产管理要求，互联网开放端口必须要经过安全部门审核，所有服务器统一使用堡垒机登录，杜绝弱口令行为等等。
安全与业务是对冤家，不打不相识，懂得技术，撩得业务，才是合格的甲方安全。
作者：雨水 | 安全服务 PM，X 安全特邀专家
最大的荣誉感是把售前大咖们吹的牛落地实现。
转载请联系 X 安全授权，感谢关注，欢迎安全行业大咖投稿。
Select Language