工业落地-蚂蚁安全-柳星《FXY：Security-Scenes-Feature-Engineering-Toolkit》
FXY：Security-Scenes-Feature-Engineering-Toolkit
https://github.com/404notf0und/FXY/blob/master/docs/%E9%9C%80%E6%B1%82%E5%92%8C%E8%AE%BE%E8%AE%A1.md
介绍
FXY是一款特征工程框架，用于安全场景中数据预处理、数据预分析、数据特征化和向量化等任务。FXY这个名字一方面代表这款工具的目的是从原始安全数据中获取Feature X和Feature Y用于对接人工智能算法，另一方面寓意着人工智能的本质，函数Y=F(X)。FXY的特性是支持多种安全场景多种安全数据的预处理和特征化，内置多种NLP通用特征提取方法，内置脚本扩展支持二次开发。
需求
无论机器学习、深度学习还是强化学习应用在哪个领域，其处理流程主要有五个环节：问题->数据->特征化->算法->结果，数据的数字化，狭义的来说是数据的特征化，在整个流程中起到了承上启下的关键作用，承上，特征化的好坏直接反映了对问题本质的理解深入与否，启下，作为算法的输入，一定程度上决定了最终结果的天花板。这是FXY定位于安全场景下特征工程环节的一点原因。另一点原因是考虑到算法环节的不确定性因素和确定性因素，不确定性因素导致难以形成统一的范式，确定性因素导致问题已被解决。就算法的应用来说，机器学习算法、深度学习算法和超参数众多，在同一特征化方法下，难以客观比较不同算法的性能，并且找到泛化性强的SOTA算法。就算法本身来说，现有的框架tensorflow、keras等对算法的封装已经很完美了，重复造轮子意义不大。如果给算法环节盖上安全场景的帽子，问题依然如此，这是FXY不选择定位于安全场景下算法环节的原因。
架构设计
因为机器学习解决安全问题的流程固定为安全问题->数据->数字化->算法->结果，具体到FXY的架构设计，从下到上依次是安全场景层->数据的数据层->数据清洗层->特征层->算法层->API层，对应的FXY各模块层次结构依次为内置函数模块->数据预处理模块->特征工程模块->tensorflow/keras->控制器模块。
扩展可扩展的，因为安全场景较多且杂，完全不可能用一种或少数几种特征方法解决所有问题，想到的一种解决方式是针对安全问题做特征方法的插件化扩展，把每个安全问题对应每个CMS，每个feature engineering方法对应每个POC，那么就可以像写CMS POC一样专注于安全场景的底层数据feature engineering。
集成
笔者Github上AI-for-Security-Learning仓库专注于知识，而此FXY仓库专注于工具，现依赖前者仓库，笔者开始二刷，站在前人的肩膀上，不断集成优质方法到FXY框架中，此框架不做未知的创新。现已集成4种安全场景，4种特征工程方法，四种安全场景分别是LSTM识别恶意HTTP请求@cdxy，AI-Driven-WAF@exp-db，Phishing URL Classification@surajr，使用深度学习检测XSS@Webber，基于深度学习的恶意样本行为检测@ApplePig@360云影实验室，四种特征工程方法分别是钓鱼url的统计特征，恶意url和恶意软件api的词典索引特征，恶意url的TF-IDF特征，xss的word2vec词嵌入向量。
在二刷并集成的过程中，需要彻底读懂原作者的文章思路和代码，然后改写到FXY限定的框架中，学到了很多。同时输出一份二刷笔记，里面不但包括已集成代码到框架中的原文理解，还包括一些暂时无法集成的文章的理解，文档化记录了原作者用到的安全场景、解决的思路、数据的构成、数据预处理方法、特征的方法、使用的模型、有无监督分类，二刷笔记持续更新。
潜在问题
FXY框架专注于安全问题、数据和特征化三个环节:这其中数据环节存在数据源难获取的问题，有些文章中的数据属于公司级数据不会开源，较难获取，这导致只能使用开源数据集或自己采集数据集复现原作者的实验，集成并测试框架，虽说不会影响FXY框架的预处理、预分析和特征化等主要功能，但这会导致数据环节数据本身的价值变小，一定程度上减小了FXY框架的价值，因为可能大多数人遇到的问题不是没有方法，而是没有数据，数据本身的价值和数据分析的价值都很高，前者价值甚至大于后者。而CMS的POC框架可以靠各种搜索引擎和爬虫来获取数据源，输送给POC脚本，就不会存在此问题。
这促使我们是不是可以通过爬虫爬取更多异源开源数据，用开源弥补闭源，或是本地搭建环境采集数据，缓解数据源缺失的问题，从而使FXY框架的价值不只在于数据分析，更在于数据集本身，采集数据集是个脏活累活，在规划中。