Hacking Team是一家专注于开发网络***软件嘚公司他们开发的软件可以***几乎所有的桌面计算机和智能手机，包括Windows、Linux、Mac OS、iOS 、Android、Blackberry、Symbian等等Hacking Team不仅提供***程序，还提供能够协助偷偷咹装***程序的未公开漏洞（0day）真是***服务。

Hacking Team的客户不乏各国的执法机构甚至包括了联合国武器禁运清单上的国家，不愧为新时代嘚IT军火供应商搞笑的事情发生了，在我们的印象 中军火商都应该是荷***实弹、戒备森严的，可是Hacking Team的老板一觉醒来却发现自己的军火倉库和帐房被偷了个底朝天。

那么Hacking Team被盗了什么？简单来说就是军火库、帐房和衣橱都被洗劫了：

1、各种平台的木马程序（含源代码）

2、协助各种木马植入的未公开漏洞（0day）

3、大量电子邮件，包括各种商业合同

4、Hacking Team内部部分员工的个人资料和密码

5、其他资料包括项目资料囷一些***的录音

Team并非第一家被黑的"网络军火"公司，去年英国的另外一家监控软件公司Gama也是同样被黑而一年之前，另一家科技监控公司Finfisher遭遇了同样方式的黑客入侵泄露400GB的内部文件。"网络军火"业务一方面游走在法律的边缘虽然能满足一部分执法部门的需求，但也非常容噫被滥用从而容易引发其他国家和一些组织的敌视。有消息显示目前HT被部分政府部门用于***记者信息系统。此外作为一家以网络監听为主营业务的公司，在自身的信息安全防护上如此大意也是本次事件的重要起因。

首先Hacking Team的系统管理员疏忽大意导致个人电脑被入侵。

正常情况下系统管理员用来进行维护的电脑应该和办公电脑隔离，并且不要轻易接入互联网但是Hacking Team的系统管理员显然是在同一台机器上既进行公司的IT系统管理，还访问互联网甚至用来管理个人的视频和照片，这就给了攻击者渗透入侵的机会

其次，系统缺少严格的身份认证授权使得攻击者顺藤摸瓜进入内网

安全防护级别较高的网络，并不会简单地对某个设备进行信任而是采用“双因素认证”来雙重检查访问者的身份，而Hacking Team显然并没有这么做这使得攻击者在控制了管理员的个人电脑后，无需经过再次认证（比如动态令牌） 就可鉯访问Hacking Team的所有资源。

因为没有严格的网络审计或者异常流量监测所以400GB数据被拖都未能及时发现。从攻击者入侵内网到攻击者将所有的資料全部偷走，需要一个较长的时间 在这个时间内，任何异常行为或者异常流量的报警都可以提醒Hacking Team的员工自己公司的网络正在被入侵。而实际上却是直到攻击者公布了所有资料，Hacking Team才知道自己被黑

不使用数据加密技术导致所有敏感数据都是明文存放。

为了防止数据泄密有较高安全级别的组织一般都会采用数据加密技术，对敏感程度较高的数据进行防护这些数据一旦脱离了公司内网，就无法打开泹是本次泄露的数据均为明文，说明Hacking Team几乎没有采用数据加密手段去保护合同、客户信、设计文档、攻击工具等

上述的所有疏忽导致了今忝的结局，中国有句俗话：终日打雁反被雁啄了眼。这句话用来形容Hacking Team再适当不过了

这次失窃会产生哪些影响？

本次Hacking Team泄漏事件的后果十汾严重过去无论是漏洞还是病毒木马，在互联网上的传播都是小范围的白帽子黑客固然会严守职业道德，在厂商提供补丁前尽可能不公布漏洞细节黑帽子也只是在地下圈子内进行漏洞交易，有点像：人人都曾经听说过黑火药的配方但要制作出军用炸药还遥遥无期。

洏此次事件一下就把已经工程化的漏洞和后门代码全部公开了等于数万吨TNT炸药让恐怖分子随意领取。

1、首当其冲的是普通用户本次泄露包括了Flash player、Windows字体、IE、Chrome、Word、PPT、Excel、Android的未公开漏洞，覆盖了大部分的桌面电脑和超过一半的智能手机

这些漏洞很可能会被黑色产业链的人利用來进行病毒蠕虫传播或者挂马盗号。上述的漏洞可以用于恶意网站用户一旦使用IE或者Chrome访问恶意网站，很有可能被植入木马而Office Word、PPT、Excel则会被用于邮件钓鱼，用户一旦打开邮件的附件就有可能被植入木 马。

2、本次泄露的各平台的木马后门程序会把整个灰色产业链的平均技術水平提高一个档次。

例如全平台的监控能力以及对微信、whatsapp、skype的监控功能等等。在此次事件之前灰色产业链的软件工程能力并不高，朩马以隐藏为主但是界面友好程度和易用性都还有很大的差距，但是本次事件后 任意一个木马编写者都可以轻易地掌握这些技术能力。

3、掀起一波清查恶意软件后门的行动相关的信息安全公司和国家政府职能部门会对PC、智能手机进行清查，同时对Hacking Team的服务器进行扫描定位也会进一步排查各种应用程序市场，智能手机的安全会引起大家的进一步重视

普通用户如何做好防范？

1、跟踪此次事件的发展各廠商发布补丁后及时升级。在没有***相应补丁前暂停使用相关的应用和插件。（例如暂时删除或者禁用Flash Playe）

2、无论是手机还是电脑，暫时不要访问不可信的网站（因为本次泄露的0day中有针对浏览器的攻击方法）暂时不要用公开的Wi-Fi，也最好不要暴露在公网上将手机连接箌电脑要慎重（Hacking Team提供了利用企业***植入智能手机的木马程序），对第三方发送的邮件附件要谨慎打开（本次泄露涉及到Office Word、excel、ppt的漏洞利鼡）。

3、安卓用户可以去下载西雅图0xid小组发布的HT木马查杀工具：点击

需要随时掌握事件的进一步发展的话可关注：新浪微博： ， 的信息哏进

作者：伯乐在线 - 艾凌风

1913 年美利堅工业之神――亨利福特，发明了世界上第一条流水线汽车工业从此进入了大规模生产的时代。丰田公司提出的丰田生产系统（Toyota Production System）又为汽车工业带来了很多先进的生产和管理理念

先进的生产和管理理念是一个行业从小作坊走向规模化的必经之路，软件工业虽然诞生较晚但是发展却非常迅速，这也同样得益于软件工业开发和管理理念的发展这其中就从汽车工业吸收了很多成熟的理念。

下面就让我们通过这张出自 Toggle 的漫画，来了解软件开发模式的变迁史

这张图片从上向下，五个房间分别是瀑布模型（waterfall），敏捷开发（agile）看板（KANBAN），SCRUM 囷精益软件开发（lean）

除了瀑布模型这间小屋和其他小屋有着明显的界限之外，其他几种模型就像一个四合院有着不可分割的关系，这吔恰好表明瀑布模式和敏捷开发模式是软件工业先后经历的两个阶段，而 KANBANSCRUM 和 LEAN 则是敏捷运动的产物。

OK客官里边请，让我们进第一个屋孓看看

旧时代 ――瀑布式软件开发

所谓瀑布模型，就是说软件开发是按照一定顺序展开的（传统线性生产流程 : Traditional,linear production flow）。就像汽车生产的流沝线一样每个部门各司其责，工作按照顺序展开交付件单通道线性流动。你看这幅图总体上就分为：需求 → 设计 → 制造 → 测试，四個阶段

在这个系统中，客户被排除在生产系统之外（围墙是密闭不透明的）它们只能从需求的接口人那里向系统输入需求（Client places order）。正因洳此客户无法理解生产所需的费用以及为什么交付总是会延期，因此也难免会闹出下面这样的笑话：

客户希望你造一辆汽车，却只愿意支付一辆自行车的开发成本

需求接纳后进入到设计阶段：

设计定型后，进入制造阶段：

在线性的生产系统中或者说在瀑布开发模式Φ，需求和设计是不可以进行修改的工人被安排在制造系统中一个个工位上，每个人仅负责一个部件的生产和装配就像这位盘腿坐着嘚“I know HTML”大哥一样，HTML 开发者只需要负责 HTML 的开发而无需也不应该关心软件的其他部分。

喂喂喂这位老铁，不上班玩什么球啊哎，您也别怪他毕竟交付件（整车/软件）还没有完成开发，测试工作自然无法开展当然得等着咯。这也是瀑布模型最大的弊端下游工作的开展嚴格依赖于上游交付件的完成情况，这无疑是一种浪费在争分夺秒的软件开发过程中，你能忍受这种浪费吗

汽车完成生产和测试之后，一次***付到客户手中完成客户的全部需求。

走进新时代――敏捷开发模式

敏捷开发以用户的需求进化为核心采用迭代、循序渐进嘚方法进行软件开发。在敏捷开发中软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试具备可视、可集成和可運行使用的特征。换言之就是把一个大项目分为多个相互联系，但也可独立运行的小项目并分别完成，在此过程中软件一直处于可使鼡状态

有点书面是吧其实很简单，敏捷开发的一个前提假设是：用户不可能在产品开发之前设计之初就完整、明确的提出需求。期望鼡户在开发过程中不变更需求是不现实的用户在开发前提出的需求，可能并不是它们最终希望得到的

在敏捷开发中，客户会参与到软件开发的整个流程中整个开发过程不再是一堵不透风的墙，透明是关键（TRANSPARENCY IS KEY）但是，随着越来越多的用户参与进来越来越多的问题也暴露出来了，越来越多不着调的需求也会被提出

敏捷开发的另一个重要概念就是迭代，所谓迭代就是不断对产品进行细微的、渐进式嘚改进（Small incremental changes）。

“先给您上个小号的尾翼用着好我再给您换个大的~”

在敏捷开发中，生产不再是线性的开发的同时还会进行测试工作，所有人都在同时工作尴尬等待的日子一去不复返咯~

利用敏捷模式开发出的产品，相较于传统的软件交付方式一个显著的特点是能够及時响应客户需求的变更，不断适应新的趋势

这不，隔壁老王喜当爹了之前定的法拉利显得有点不稳重，宝宝也没地方坐我们的产品經理和开发人员快速响应，轿跑变商务也不是什么大问题~~ 当然为谁辛苦为谁忙，客户爸爸们一定要买单呀！

什么您问第一稿方案是什麼样的？去翻垃圾桶吧！

一股来自东方的神秘力量――看板

相信各位也注意到了相对于瀑布模式的井井有条，敏捷开发在灵活的同时吔带来了一定程度的混乱。

就在这个节骨眼上还得请这位来自东方的神秘人物――丰田看板大师（KANBAN SENSEI）给你点拨点拨。

KANBAN不是汉语拼音，哽不是英文缩写它来自日语“看板”，カンバン的罗马拼写：Kanban它正是丰田生产系统的一个重要概念：

看板管理，常作“Kanban管理”是丰畾生产模式中的重要概念，指为了达到及时生产（JIT）方式控制现场生产流程的工具及时生产方式中的拉式（Pull）生产系统可以使信息的流程缩短，并配合定量、固定装货容器等方式而使生产过程中的物料流动顺畅。

KANBAN要求把开发中的任务以 TODO List 的方式表现出来：

形式可以是即時贴，也可以是可视化软件等等

在制造业中，看板也是非常重要的管理方法也有将其称为目视化管理的。

Scrum原始含义是指英式橄榄球次偠犯规时在犯规地点对阵争球争球双方各有8个队员参与，各方出3名前锋队员并肩各站成一横排，面对面躬身互相顶肩中间形成一条通道，其他队员分别站在后面后排队员用肩顶住前锋队员的臀部，组成3、2、3或3、4、1阵形然后，由犯规队的对方队员在对阵一侧1码外鼡双手低手将球抛入通道，不得有利于本队当球抛入通道时，前排的3对前锋队员互相抗挤争相踢球给本方前卫或后卫队员，前卫和后衛队员必须等候前锋将球踢回后方可移动

在敏捷开发领域，SCRUM是一种迭代式增量软件开发过程它包括了一些预定义的角色：

产品负责人負责维护订单

在 SCRUM 过程中，开发团队通常会进行冲刺 （Sprint）一个冲刺周期的长度通常是2-4周。

在这个冲刺过程中开发小组专注于完成一组订單项的开发。比如：制造一个发动机

对于KANBAN 和 SCRUM有人说 KANBAN vs SCRUM，也有人说 KANBAN+SCRUM究竟谁是谁非，我看只有适合自己团队的才是最好的毕竟方法和流程昰为业务服务的。就这篇漫画来看SCRUM + KANBAN 是两个避免混乱的好方法。

来来来兄弟们，我们来开一个关于减少站会的站会~~

第二次世界大战结束後丰田公司前社长丰田英二曾经去美国汽车城底特律对福特生产线进行了考察，尽管福特高效的大规模生产线给他造成了很大的冲击豐田英二还是非常理智的认识到了当时日本制造业所面临的困难。经济萧条资源短缺，小批量差异化的需求使他不能盲目的引进这种大規模的生产方式随后丰田公司发明并实践了一系列的管理和生产方法，这些方法在后来被统称为精益生产和管理方式（lean）

精益生产的思想 简单来说就是Just In Time（JIT），也就是说只在必要的时候，按照需求的量仅生产必要的产品，杜绝浪费

Eric Ries曾在《精益创业实战》中提出MVP（minimum viable product）概念，意即“最简可行产品”――用最快、最简明的方式建立一个可用的产品原型这个原型要表达出你产品最终想要的效果，然后通过迭代来完善细节

精益软件开发不再像传统的软件开发一样，耗时几年才向客户交付完整的软件取而代之的是，优先建立一个最简可用嘚原型产品投放市场或交付到客户手中

一辆最简可用的汽车是什么样子的呢？不就是四个轮子、一个方向盘、一个座椅然后一起装在底盤上么能开、能停、能转弯不就是汽车嘛。让客户先享受到产品带来的收益是最重要的

你看，这里还有一位失落的大叔

尽管MPV 的概念听仩去是如此的简单可是实施起来却没有那么容易。

因为在设计产品原型的过程中很多设计师是这么做的：把他们认为的产品应当具备嘚功能罗列出来，然后一一排除排定优先级，决定哪个功能要在最初的版本中出现而哪个可以靠后一些。但设计师们往往无法真的只紦最必要的功能留在初级版本中――因为诱惑太多设计师们总希望把很cool、很有惊喜的小细节带给用户来博取赞叹，但从全局来看其实紦某些功能刻意强加进产品，是会削弱产品整体流畅性的Mr Jamie曾在其博客中把这种心理表现称作“艺术家心结”。

所有不必的东西（ALL NON-ESSENTIALS ARE THROWN OUT）都不能应用到当前的最小可用产品你说，艺术家们得多伤心啊（愁的胡子都长一脸了）

此外尽早交付产品给客户或部署到生产环境，也促進了 DevOps持续集成（CI），生产环境测试（testing in production）等实践的发展尽早交付产品，尽早从用户获取反馈不论是好的还是坏的，促使问题尽早暴露尽早修复，持续集成持续改进。

眼尖的童鞋估计早就看到了桌子上有一只程序员的好朋友 ―― 小黄鸭。你还不知道小黄鸭那你该看看这篇文章：《小黄鸭调试法，每个程序员都要知道的》

实际工作中的软件开发和管理模式，往往并不能纯粹的归类于以上某种类型即使是相同的开发模型，在不同的团队中也往往会根据实际情况进行变化和改进留言告诉我们你所在的公司是如何进行软件开发的吧~

此外，如果你对我的解析有不同的看法或者你在图中看出了新的内涵，也欢迎在评论中互动！