Addressing review comments for chapter 3, section 3.4 and adding a co…

…nclusions section. References #5

Chapters/02-byodSotA.tex

@@ -120,23 +120,26 @@ \section{Research lines in BYOD}
 
 It is interesting to mention that previous works are mainly focused in separating into hands-off vs hand-on devices, or static analysis techniques. However, neither of the papers found in bibliography establishes a taxonomy. In addition, the tools described in the reviewed works, do not implement any security policies adaptation methods, as the methodology we present in this thesis.
 
-\section{Tools for corporate mobile security}
-\label{sec:toolsreview}
+\section{A taxonomy for the classification of BYOD tools}
+\label{sec:taxonomy}
 
-Many tools for companies, as well as for devices, that help in adopting the BYOD philosophy have been released in the past years. From the point of view of the enterprise, there are some tools which offer the CSO ways to control the devices which enter into the system, for instance, and also to protect the employees' data by means of data encryption and data protection by requiring the use of strong and secure passwords. Other tools for managing a BYOD situation add to their features guidelines for the CSOs to develop good ISPs, like Good's BYOD solution (see Section \ref{subsec:othertools}). On the other hand, many solutions have been presented which are more focused on the device side, although they implement also the server side. This is the case, for instance, of Android for Work (see Section \ref{subsec:androidwork}). Some of those tools have influenced the development of the MUSES system  itself (Appendix \ref{chap:appendixmuses}), which can complement them, as adds other features that go beyond the state of the art. 
-
-The products that have been reviewed were chosen either because they have appeared in top-10 web articles \cite{thor2013}, or they have been developed for the main smartphone platforms \cite{idc2014}. Actually, the selection process have been difficult, as some of the initially found tools or companies in the web were bought by others that we do review here. Also, because this market is still growing, there are not many solutions to review, and here we display the ones more alike to MUSES. This section introduces the most relevant features of these products, as they can be considered related to the MUSES objectives.
-
-As these tools have several access levels, different detection methods, or diverse data control, there exist a number of aspects that the end-users need to take into account to validate if a product fits their needs. Therefore, we propose the next taxonomy in order to classify the BYOD tools described in this section.
+As the reviewed tools have several access levels, different detection methods, or diverse data control, there exist a number of aspects that the end-users need to take into account to validate if a product fits their needs. Therefore, we propose the next taxonomy in order to classify the BYOD tools described in this section.
 
 \begin{itemize}
-\item {\em Online or offline threat detection method}. This kind of tools can identify security threats during runtime (online) or before their implantation (offline). For example, using some kind of DM technique, such as classification methods, or merely the system administrator experience, can be used to generate rules before the deployment of the tool (offline) to detect threats in runtime. However, new rules cannot be added. On the contrary, a real-time adaptation using actual data sources, that modify the parameters of the detection system, follows an online scheme.
+\item {\em Online or offline threat detection method}. This kind of tools can identify security threats during runtime (online) or before their implantation (offline). For example, using some kind of Data Mining (DM) technique, such as classification methods, or merely the system administrator experience, can be used to generate rules before the deployment of the tool (offline) to detect threats in runtime. However, new rules cannot be added. On the contrary, a real-time adaptation using actual data sources, that modify the parameters of the detection system, follows an online scheme.
 \item {\em Updatable or fixed information database}. This classification is related to the previous one. New information gathered by the system during runtime can be stored in a database to generate new rules. If this database is not changed during runtime, as in the offline example explained above, the database is {\em fixed}. An example could be the hand-coded rules of a firewall, such as {\em iptables}, obtained from an offline method. On the other hand, an updatable database, such as the system logs, that can be used to extract new information, may offer more valuable data source for dynamic adaptation mechanisms. However, it is not mandatory for an online threat detection method to use an updatable database, as current data may be analyzed and deleted once a new rule is created. 
 \item {\em Based in an external service or standalone}: A standalone tool do not require a external service to be used. For example, a basic firewall. However, as mentioned by \cite{Romer14BestPractices} in previous section, a service for threat monitoring, or a private cloud usage are good practices to apply in BYOD.
 \item {\em Invasive or non-invasive data access}. A system can be considered {\em invasive} if a user must use a certain tool to perform their job. For example, opening a specific browser provided by the tool, instead of the original device browser, such as Chrome of Safari. An example of an invasive marketplace is the one proposed by \cite{Armando14metamarket} and discussed in previous section. Instead, a {\em non-invasive} data access is transparent to the user. An example is a log analyzer daemon that updates other program configurations or sends information to the company server.
 \item {\em Superuser or non-superuser system control}. Using a tool in superuser mode would add more information and control than a non-superuser running mode, as it can access to elements of the device usually forbidden for regular applications, such as network, logs or other devices. However using superuser control may lead to a lack of user privacy, as explained in \cite{Gessner13userfriendly}.
 \end{itemize}
 
+\section{Tools for corporate mobile security}
+\label{sec:toolsreview}
+
+Many tools for companies, as well as for devices, that help in adopting the BYOD philosophy have been released in the past years. From the point of view of the enterprise, there are some tools which offer the CSO ways to control the devices which enter into the system, for instance, and also to protect the employees' data by means of data encryption and data protection by requiring the use of strong and secure passwords. Other tools for managing a BYOD situation add to their features guidelines for the CSOs to develop good ISPs, like Good's BYOD solution (see Section \ref{subsec:othertools}). On the other hand, many solutions have been presented which are more focused on the device side, although they implement also the server side. This is the case, for instance, of Android for Work (see Section \ref{subsec:androidwork}). Some of those tools have influenced the development of the MUSES system  itself (Appendix \ref{chap:appendixmuses}), which can complement them, as adds other features that go beyond the state of the art. 
+
+The products that have been reviewed were chosen either because they have appeared in top-10 web articles \cite{thor2013}, or they have been developed for the main smartphone platforms \cite{idc2014}. Actually, the selection process have been difficult, as some of the initially found tools or companies in the web were bought by others that we do review here. Also, because this market is still growing, there are not many solutions to review, and here we display the ones more alike to MUSES. This section introduces the most relevant features of these products, as they can be considered related to the MUSES objectives.
+
 
 %----------------------------------------------------------------------------
 
@@ -147,7 +150,7 @@ \subsection{IBM Mobile Security}
 
 Main services offered by IBM can be divided into three categories: Mobile Enterprise Services, Hosted Mobile Device Security Management, and Enterprise Wireless Networks. However, here we only discuss the former, because it is the only one related to BYOD. Mobile Enterprise Services is offered as an integrated solution for smartphones and tablets as well, but then it is divided in different sub-services that the company has to acquire separately. Some of them are related, to cloud computing. Among them, there is one which is interesting for the scope of BYOD, the so-called `hosted vulnerability management'. This sub-service seems to implement one of the most important advantages of the MUSES system, the self-adaptation. IBM performs deep scans over the security incidents data, either by computer forensics analysis, if the incident happened, or by normal data, if the device was enough secure. They claim in their website \cite{ibmVulnMgm} that their tool is able to recognize new vulnerabilities or threats with enough accuracy. 
 
-The specific IBM products related to BYOD security are included in their {\em MobileFirst} \footnote{\url{http://www.ibm.com/mobilefirst}} suite. MobileFirst is a set of mobile applications and services, based in big data analytics and cloud computing. It includes several products, such as a framework for app development (MobileFirst Platform), a Platform as a Service (BlueMix) or a threat detection system (Trusteer Rapport). However, the most interesting one with respect to this work scope, is {\em MobileFirst Protect}. This product, formerly known as {\em MaaS360} \footnote{\url{http://www.maas360.com/}}, is an MDM (Mobile Device Management) software to secure, monitor, and manage mobile devices. It uses a web portal in order to centralize the security and control policies. This allows the deployment of applications or backups, among other possibilities. However, MobileFirst Protect seems a typical MDM tool, which just applies the existing set of security policies. No further risk and trust analysis is performed, neither is included a refinement of the rules derived from the policies.
+The specific IBM products related to BYOD security are included in their {\em MobileFirst}\footnote{\url{http://www.ibm.com/mobilefirst}} suite. MobileFirst is a set of mobile applications and services, based in big data analytics and cloud computing. It includes several products, such as a framework for app development (MobileFirst Platform), a Platform as a Service (BlueMix) or a threat detection system (Trusteer Rapport). However, the most interesting one with respect to this work scope, is {\em MobileFirst Protect}. This product, formerly known as {\em MaaS360}\footnote{\url{http://www.maas360.com/}}, is an MDM (Mobile Device Management) software to secure, monitor, and manage mobile devices. It uses a web portal in order to centralize the security and control policies. This allows the deployment of applications or backups, among other possibilities. However, MobileFirst Protect seems a typical MDM tool, which just applies the existing set of security policies. No further risk and trust analysis is performed, neither is included a refinement of the rules derived from the policies.
 
 The main difference with MUSES in this case, is that MUSES includes the threat recognition feature feature in the system, without the need of purchasing the service separately and configuring the different parts. Another difference is the fact that IBM software is not open source as MUSES system is. Then, to verify the success of this feature is highly difficult, as they do not present statistics in their website either. In addition, this product also offers the possibility to work offline, though an initial online authentication is needed \cite{mobFirstAuth}. 
 
@@ -350,3 +353,6 @@ \section{A comparison between tools}
 GP has been previously proposed in bibliography \cite{rule_generation_gp_09,sec_policy_evolution_gp_08}, even for creating new policies or rules in a security-aimed sense. In any case they do not affect the ISPs and moreover, our proposed evaluation functions, completely integrated in the system, for the refinement and inference approaches are novel.
 
 With respect to GA, they have been extensively used in this scope in the literature, mainly for the detection of anomalies and intrusions rather than for optimization, as it is used in the proposed system. However, there are some examples that could be used as model for our approach, such as \cite{EAs_securitycosts-kirta,risk_reduction_ga_12}.
+
+\section{Conclusions}
+\label{sec:sota_conclusions}