首页
社区
课程
招聘
[转帖]确保企业系统安全的13条原则
发表于: 2013-4-3 20:05 1891

[转帖]确保企业系统安全的13条原则

2013-4-3 20:05
1891
http://www.enet.com.cn/security/ 2013年02月21日18:15 来源:TechTarget中国


在新年开始之际,笔者建议你在设计新系统时采用这13个原则。虽然13并不认为是吉利的数字,但笔者相信,当你将这些原则在企业中付诸实践时,将会给你带来好运气。

13条安全设计原则

1)保护最薄弱环节–-Spaf(即备受推崇的普渡大学安全专家Gene Spafford)通过一个有趣的故事来说明这个原则。试想一下,你需要负责把睡在公园长椅上的无家可归的人(我们称他为Linux)的财产运送给另一个无家可归的女人(我们称她为Android),你租用了一辆装甲卡车来运送,运输公司的名称是“Applied Crypto, Inc.”。现在,假设你是准备窃取财产的攻击者,你是会攻击Applied Crypto卡车、无家可归的人Linux还是无家可归的女人Android?很容易做出选择吧?(提示:答案是,“除了卡车以外”)

笔者及其合著者John Viega在2001年撰写的《构建安全软件》一书中写道,“安全从业者经常指出,安全就像一根链条,链条的强弱取决于其最薄弱的环节,同样的道理,软件安全系统的安全性也取决于其最薄弱的组件。”攻击者往往会寻找系统中最薄弱的地方,而最薄弱的地方很少会是某个安全功能或特性。当涉及到安全设计时,一定要考虑你的系统中最薄弱的环节,确保它是足够安全的。

2)深度防御–笔者和Kenneth van Wyk喜欢将这个称为“腰带和吊袜带”的方法。在安全领域,冗余和分层通常是好事。不要指望你的防火墙来阻止所有恶意流量;同时还应该使用入侵检测系统。如果你正在设计一个应用,通过安全冗余和防御层来防止单点故障。《构建安全软件》中提到:“深度防御背后的概念是管理不同防御策略的风险,这样的话,即使某个防御层无法提供足够的安全性,另一个防御层将有可能防止数据泄露。”这是信息安全专家普遍认同的概念,理由很简单:它有用。

3)保证失效后的安全性—请确保你设计的系统不会在失效后保持“开放”。关于这个原则,笔者最喜欢的故事是命运多舛的Microsoft Bob产品(Bob是Clippy回形针的前身),据传说,如果你三次尝试输入用户名和密码失败后,Bob将会询问你是否要选择使用一个新密码,感谢Bob(攻击者说)!很显然,在这种情况下,更好的默认设置应该是拒绝访问。

《构建安全软件》中提到:“任何足够复杂的系统都会失效,失效是不可避免的,企业应该提前做好准备。可以避免的是与失效相关的安全问题。但问题是,当很多系统以任何方式失效时,它们都会表现出不安全行为。”

4)最小特权—当你需要为用户或进程授予权限来完成一些操作,尽可能授予最小的权限。想想你的Outlook联系人列表,如果你需要别人访问你的联系人列表来查看一些数据,授予他们读者权限,但不要授予编辑权限。这有一个更专业的例子:系统的大多数用户的日常工作并不需要根级权限,所以不要授予他们根级权限。底线是,避免无意的、不必要的或不正确的权限使用,以“吝啬”的方式来授予权限。

5)独立权限—笔者曾经看到一个系统将其认证前端划分成大量角色,这些角色对系统有不同程度的访问。问题是,当任何角色的用户需要执行后端数据库操作时,该软件会临时授予每个用户管理员权限。这样做并不好,即使是最底层的实习生也可以侵入数据库。要知道,如果攻击者可以骗取一个权限,而无法得到第二个权限时,他将无法成功发起攻击。所以保持权限的分离。

6)经济机制—复杂性是安全工程的敌人,却是攻击者的朋友。无论是从设计的角度来看,还是从部署的角度来看,在复杂的系统中,很容易将事情“搞砸”。具有讽刺意味的是:想看看复杂的东西吗?只要看一看现代企业软件的任何一部分。

尽可能保持事物简单。《构建安全软件》中提到,“KISS的口头禅众所周知:‘保持简单,保持愚蠢!(Keep It Simple, Stupid!)’这个说法同样适用于安全领域及其他任何领域。复杂性增加了问题的风险,避免复杂性,就是避免问题。”

7)不要共享机制—你是否应该将面向内部的业务应用放在公共云中?根据这条原则,最好不要。你可以将你的身份验证系统限制为你信任的员工,为什么让你的系统处理随机互联网流量呢?

还有一个专业的例子:如果你有多个用户使用相同的组件,让你的系统为每个用户创建不同的实例。不共享用户之间的对象和访问机制,可以减少安全故障的可能。

8)不要轻易信任—假设你的系统运行的环境处于不利条件,不要让所有人都能调用你的API,当然也不要让所有人能够访问你的机密信息。如果你依赖于云组件,你需要对其进行检查,以确保它没有被欺骗或者受到感染。预防命令注入、跨站脚本等攻击。在《构建安全软件》中,“最后一点要记住的是,信任是可传递的,当你给出信任时,你往往会将这种信任扩展到你信任的实体所信任的对象上。”

9)假设你的机密信息并不安全—安全不能“含糊其辞”,特别是当涉及存储在你的代码中的秘密信息时。假设攻击者能够找出关于你的系统尽可能多的信息,甚至可能超过超级用户。攻击者的工具包有反编译器、反汇编器以及很多分析工具。假设他们瞄准了你的系统,他们怎么查看二进制码中的加密密钥?函数扫描会让加密密钥呼之欲出,毕竟二进制只是一种语言。

10)彻底检查--企业应该对每次访问和每个对象进行检查。请确保你的访问控制系统是全面的,适应当今这个多线程世界的。不管你做什么,如果更改系统权限,请确保对访问进行了系统化的重复检查。不要缓存授权或使用权的结果。在充满大规模分布式系统和多处理器计算机的世界,这条原则非常重要。

11)使安全可用—如果你的安全机制太繁琐,你的用户会想尽办法规避或避免它们。请确保你的安全系统足够安全,但也不要“过头”。如果你深深地影响了可用性,没有人会使用你的东西,不管它多么安全。虽然它非常安全,但同时也非常没用。Spaf经常会笑话据称是世界上最安全的系统,即系统硬盘消磁,被埋在填满混泥土的30英尺的围绕法拉第电网的洞里。这样的系统肯定很难使用。

12)保护隐私--大家都在谈论保护隐私,但大多数人实际上没有做任何相关事情。你可以帮助解决这个问题。当你设计一个系统时,考虑一下最终用户的隐私。你收集个人识别信息(PII)只是因为市场部有人要求这样做吗?这样做好吗?你是将PII存储在可能受到破坏的地方吗?难道不应该对这些信息进行加密吗?信息安全从业人员并不需要提供对这些隐私问题的答案(这是首席信息官的工作),但如果没有其他人提出这类问题,你需要提出。

13)使用你的资源—正如笔者14岁时在童军领导培养课程中学到的那样,“使用你的资源”这条原则具有令人难以置信的广泛应用范围。如果你不确定你的系统设计是否安全,请寻求帮助。架构风险分析很难,但有些人已经做了几十年。如果你做不到的话,最好不要尝试单独操作。不要羞于寻求帮助,这件事情非常复杂。

借用别人的好点子

笔者永远都不会忘记在硅谷的HSARPA会议演示软件安全幻灯片的那天。这个幻灯片是基于笔者的《构建安全软件》一书中的内容,该书有一章是围绕这些安全原则。其中一张幻灯片是Saltzer和Schroeder的图谱,你猜谁正好坐在观众席中?正是Michael Schroeder本人,他赞扬了这个幻灯片,这个世界确实很小。Saltzer和Schroeder在1975年是正确的,当我们在撰写《构建安全软件》的今天仍然是正确的。将他们的原则应用到2013年的安全工作中,不要害怕使用别人想出的好想法。

[培训]内核驱动高级班,冲击BAT一流互联网大厂工作,每周日13:00-18:00直播授课

收藏
免费 0
支持
分享
最新回复 (0)
游客
登录 | 注册 方可回帖
返回
//