The Experts below are selected from a list of 2556 Experts worldwide ranked by ideXlab platform
Michael Gegick - One of the best experts on this subject based on the ideXlab platform.
-
identifying security bug reports via text mining an industrial case study
Mining Software Repositories, 2010Co-Authors: Michael Gegick, Pete Rotella, Tao XieAbstract:A bug-tracking system such as Bugzilla contains bug reports (BRs) collected from various sources such as development teams, testing teams, and end users. When bug reporters submit bug reports to a bug-tracking system, the bug reporters need to label the bug reports as security bug reports (SBRs) or not, to indicate whether the involved bugs are security problems. These SBRs generally deserve higher priority in bug fixing than not-security bug reports (NSBRs). However, in the bug-reporting process, bug reporters often mislabel SBRs as NSBRs partly due to lack of security domain knowledge. This mislabeling could cause serious damage to Software-system stakeholders due to the induced delay of identifying and fixing the involved security bugs. To address this important issue, we developed a new approach that applies text mining on natural-language descriptions of BRs to train a statistical model on already manually-labeled BRs to identify SBRs that are manually-mislabeled as NSBRs. Security engineers can use the model to automate the classification of BRs from large bug databases to reduce the time that they spend on searching for SBRs. We evaluated the model's predictions on a large Cisco Software system with over ten million source lines of code. Among a sample of BRs that Cisco bug reporters manually labeled as NSBRs in bug reporting, our model successfully classified a high percentage (78%) of the SBRs as verified by Cisco security engineers, and predicted their classification as SBRs with a probability of at least 0.98.
-
MSR - Identifying security bug reports via text mining: An industrial case study
2010 7th IEEE Working Conference on Mining Software Repositories (MSR 2010), 2010Co-Authors: Michael Gegick, Pete Rotella, Tao XieAbstract:A bug-tracking system such as Bugzilla contains bug reports (BRs) collected from various sources such as development teams, testing teams, and end users. When bug reporters submit bug reports to a bug-tracking system, the bug reporters need to label the bug reports as security bug reports (SBRs) or not, to indicate whether the involved bugs are security problems. These SBRs generally deserve higher priority in bug fixing than not-security bug reports (NSBRs). However, in the bug-reporting process, bug reporters often mislabel SBRs as NSBRs partly due to lack of security domain knowledge. This mislabeling could cause serious damage to Software-system stakeholders due to the induced delay of identifying and fixing the involved security bugs. To address this important issue, we developed a new approach that applies text mining on natural-language descriptions of BRs to train a statistical model on already manually-labeled BRs to identify SBRs that are manually-mislabeled as NSBRs. Security engineers can use the model to automate the classification of BRs from large bug databases to reduce the time that they spend on searching for SBRs. We evaluated the model's predictions on a large Cisco Software system with over ten million source lines of code. Among a sample of BRs that Cisco bug reporters manually labeled as NSBRs in bug reporting, our model successfully classified a high percentage (78%) of the SBRs as verified by Cisco security engineers, and predicted their classification as SBRs with a probability of at least 0.98.
-
Identifying security fault reports via text mining
2009Co-Authors: Michael Gegick, Pete Rotella, Tao XieAbstract:A fault-tracking (bug-tracking) system such as Bugzilla contains fault reports (FRs) collected from various sources such as development teams, test teams, and end-users. Software or security engineers manually analyze the FRs to label the subset of FRs that are security fault reports (SFRs), which indicate a security problem. These SFRs generally deserve higher priority in fault fixing than the not-security fault reports (NSFRs). However, this manual process is time consuming and error-prone (e.g. mislabeling an SFR as an NSFR). To address these important issues, we developed a new approach that applies text mining natural-language descriptions of FRs to train a statistical model on already manually-labeled FRs to identify unlabeled SFRs or SFRs that are manually-mislabeled as NSFRs. A security team can use the model to automate the classification of FRs for large fault databases to reduce the time that they spend on searching for SFRs. We evaluated the model's predictions on a large Cisco Software system with over ten million source lines of code. Among a sample of FRs that Cisco Software engineers manually labeled as NSFRs, our model successfully classified a high percentage (78%) of the SFRs as verified by a Cisco security team, and predicted their classification as SFRs with a probability of at least 0.98. Our results also indicate that a high percentage (77%) of the SFRs identified by our model is associated with Software components that a code-level statistical model predicted to be attack-prone. Such findings provided valuable insights for calling for a future combined approach that exploits both textual information of FRs and code-level information of their associated Software components.
-
ESSoS - Toward Non-security Failures as a Predictor of Security Faults and Failures
Lecture Notes in Computer Science, 2009Co-Authors: Michael Gegick, Pete Rotella, Laurie WilliamsAbstract:In the search for metrics that can predict the presence of vulnerabilities early in the Software life cycle, there may be some benefit to choosing metrics from the non-security realm. We analyzed non-security and security failure data reported for the year 2007 of a Cisco Software system. We used non-security failure reports as input variables into a classification and regression tree (CART) model to determine the probability that a component will have at least one vulnerability. Using CART, we ranked all of the system components in descending order of their probabilities and found that 57% of the vulnerable components were in the top nine percent of the total component ranking, but with a 48% false positive rate. The results indicate that non-security failures can be used as one of the input variables for security-related prediction models.
-
ICST - Predicting Attack-prone Components
2009 International Conference on Software Testing Verification and Validation, 2009Co-Authors: Michael Gegick, Pete Rotella, Laurie WilliamsAbstract:Limited resources preclude Software engineers from finding and fixing all vulnerabilities in a Software system. This limitation necessitates security risk management where security efforts are prioritized to the highest risk vulnerabilities that cause the most damage to the end user. We created a predictive model that identifies the Software components that pose the highest security risk in order to prioritize security fortification efforts. The input variables to our model are available early in the Software life cycle and include security-related static analysis tool warnings, code churn and size, and faults identified by manual inspections. These metrics are validated against vulnerabilities reported by testing and those found in the field. We evaluated our model on a large Cisco Software system and found that 75.6% of the system's vulnerable components are in the top 18.6% of the components predicted to be vulnerable. The model's false positive rate is 47.4% of this top 18.6% or 9.1% of the total system components. We quantified the goodness of fit of our model to the Cisco data set using a receiver operating characteristic curve that shows 94.4% of the area is under the curve.
Pete Rotella - One of the best experts on this subject based on the ideXlab platform.
-
identifying security bug reports via text mining an industrial case study
Mining Software Repositories, 2010Co-Authors: Michael Gegick, Pete Rotella, Tao XieAbstract:A bug-tracking system such as Bugzilla contains bug reports (BRs) collected from various sources such as development teams, testing teams, and end users. When bug reporters submit bug reports to a bug-tracking system, the bug reporters need to label the bug reports as security bug reports (SBRs) or not, to indicate whether the involved bugs are security problems. These SBRs generally deserve higher priority in bug fixing than not-security bug reports (NSBRs). However, in the bug-reporting process, bug reporters often mislabel SBRs as NSBRs partly due to lack of security domain knowledge. This mislabeling could cause serious damage to Software-system stakeholders due to the induced delay of identifying and fixing the involved security bugs. To address this important issue, we developed a new approach that applies text mining on natural-language descriptions of BRs to train a statistical model on already manually-labeled BRs to identify SBRs that are manually-mislabeled as NSBRs. Security engineers can use the model to automate the classification of BRs from large bug databases to reduce the time that they spend on searching for SBRs. We evaluated the model's predictions on a large Cisco Software system with over ten million source lines of code. Among a sample of BRs that Cisco bug reporters manually labeled as NSBRs in bug reporting, our model successfully classified a high percentage (78%) of the SBRs as verified by Cisco security engineers, and predicted their classification as SBRs with a probability of at least 0.98.
-
MSR - Identifying security bug reports via text mining: An industrial case study
2010 7th IEEE Working Conference on Mining Software Repositories (MSR 2010), 2010Co-Authors: Michael Gegick, Pete Rotella, Tao XieAbstract:A bug-tracking system such as Bugzilla contains bug reports (BRs) collected from various sources such as development teams, testing teams, and end users. When bug reporters submit bug reports to a bug-tracking system, the bug reporters need to label the bug reports as security bug reports (SBRs) or not, to indicate whether the involved bugs are security problems. These SBRs generally deserve higher priority in bug fixing than not-security bug reports (NSBRs). However, in the bug-reporting process, bug reporters often mislabel SBRs as NSBRs partly due to lack of security domain knowledge. This mislabeling could cause serious damage to Software-system stakeholders due to the induced delay of identifying and fixing the involved security bugs. To address this important issue, we developed a new approach that applies text mining on natural-language descriptions of BRs to train a statistical model on already manually-labeled BRs to identify SBRs that are manually-mislabeled as NSBRs. Security engineers can use the model to automate the classification of BRs from large bug databases to reduce the time that they spend on searching for SBRs. We evaluated the model's predictions on a large Cisco Software system with over ten million source lines of code. Among a sample of BRs that Cisco bug reporters manually labeled as NSBRs in bug reporting, our model successfully classified a high percentage (78%) of the SBRs as verified by Cisco security engineers, and predicted their classification as SBRs with a probability of at least 0.98.
-
Identifying security fault reports via text mining
2009Co-Authors: Michael Gegick, Pete Rotella, Tao XieAbstract:A fault-tracking (bug-tracking) system such as Bugzilla contains fault reports (FRs) collected from various sources such as development teams, test teams, and end-users. Software or security engineers manually analyze the FRs to label the subset of FRs that are security fault reports (SFRs), which indicate a security problem. These SFRs generally deserve higher priority in fault fixing than the not-security fault reports (NSFRs). However, this manual process is time consuming and error-prone (e.g. mislabeling an SFR as an NSFR). To address these important issues, we developed a new approach that applies text mining natural-language descriptions of FRs to train a statistical model on already manually-labeled FRs to identify unlabeled SFRs or SFRs that are manually-mislabeled as NSFRs. A security team can use the model to automate the classification of FRs for large fault databases to reduce the time that they spend on searching for SFRs. We evaluated the model's predictions on a large Cisco Software system with over ten million source lines of code. Among a sample of FRs that Cisco Software engineers manually labeled as NSFRs, our model successfully classified a high percentage (78%) of the SFRs as verified by a Cisco security team, and predicted their classification as SFRs with a probability of at least 0.98. Our results also indicate that a high percentage (77%) of the SFRs identified by our model is associated with Software components that a code-level statistical model predicted to be attack-prone. Such findings provided valuable insights for calling for a future combined approach that exploits both textual information of FRs and code-level information of their associated Software components.
-
ESSoS - Toward Non-security Failures as a Predictor of Security Faults and Failures
Lecture Notes in Computer Science, 2009Co-Authors: Michael Gegick, Pete Rotella, Laurie WilliamsAbstract:In the search for metrics that can predict the presence of vulnerabilities early in the Software life cycle, there may be some benefit to choosing metrics from the non-security realm. We analyzed non-security and security failure data reported for the year 2007 of a Cisco Software system. We used non-security failure reports as input variables into a classification and regression tree (CART) model to determine the probability that a component will have at least one vulnerability. Using CART, we ranked all of the system components in descending order of their probabilities and found that 57% of the vulnerable components were in the top nine percent of the total component ranking, but with a 48% false positive rate. The results indicate that non-security failures can be used as one of the input variables for security-related prediction models.
-
ICST - Predicting Attack-prone Components
2009 International Conference on Software Testing Verification and Validation, 2009Co-Authors: Michael Gegick, Pete Rotella, Laurie WilliamsAbstract:Limited resources preclude Software engineers from finding and fixing all vulnerabilities in a Software system. This limitation necessitates security risk management where security efforts are prioritized to the highest risk vulnerabilities that cause the most damage to the end user. We created a predictive model that identifies the Software components that pose the highest security risk in order to prioritize security fortification efforts. The input variables to our model are available early in the Software life cycle and include security-related static analysis tool warnings, code churn and size, and faults identified by manual inspections. These metrics are validated against vulnerabilities reported by testing and those found in the field. We evaluated our model on a large Cisco Software system and found that 75.6% of the system's vulnerable components are in the top 18.6% of the components predicted to be vulnerable. The model's false positive rate is 47.4% of this top 18.6% or 9.1% of the total system components. We quantified the goodness of fit of our model to the Cisco data set using a receiver operating characteristic curve that shows 94.4% of the area is under the curve.
Tao Xie - One of the best experts on this subject based on the ideXlab platform.
-
identifying security bug reports via text mining an industrial case study
Mining Software Repositories, 2010Co-Authors: Michael Gegick, Pete Rotella, Tao XieAbstract:A bug-tracking system such as Bugzilla contains bug reports (BRs) collected from various sources such as development teams, testing teams, and end users. When bug reporters submit bug reports to a bug-tracking system, the bug reporters need to label the bug reports as security bug reports (SBRs) or not, to indicate whether the involved bugs are security problems. These SBRs generally deserve higher priority in bug fixing than not-security bug reports (NSBRs). However, in the bug-reporting process, bug reporters often mislabel SBRs as NSBRs partly due to lack of security domain knowledge. This mislabeling could cause serious damage to Software-system stakeholders due to the induced delay of identifying and fixing the involved security bugs. To address this important issue, we developed a new approach that applies text mining on natural-language descriptions of BRs to train a statistical model on already manually-labeled BRs to identify SBRs that are manually-mislabeled as NSBRs. Security engineers can use the model to automate the classification of BRs from large bug databases to reduce the time that they spend on searching for SBRs. We evaluated the model's predictions on a large Cisco Software system with over ten million source lines of code. Among a sample of BRs that Cisco bug reporters manually labeled as NSBRs in bug reporting, our model successfully classified a high percentage (78%) of the SBRs as verified by Cisco security engineers, and predicted their classification as SBRs with a probability of at least 0.98.
-
MSR - Identifying security bug reports via text mining: An industrial case study
2010 7th IEEE Working Conference on Mining Software Repositories (MSR 2010), 2010Co-Authors: Michael Gegick, Pete Rotella, Tao XieAbstract:A bug-tracking system such as Bugzilla contains bug reports (BRs) collected from various sources such as development teams, testing teams, and end users. When bug reporters submit bug reports to a bug-tracking system, the bug reporters need to label the bug reports as security bug reports (SBRs) or not, to indicate whether the involved bugs are security problems. These SBRs generally deserve higher priority in bug fixing than not-security bug reports (NSBRs). However, in the bug-reporting process, bug reporters often mislabel SBRs as NSBRs partly due to lack of security domain knowledge. This mislabeling could cause serious damage to Software-system stakeholders due to the induced delay of identifying and fixing the involved security bugs. To address this important issue, we developed a new approach that applies text mining on natural-language descriptions of BRs to train a statistical model on already manually-labeled BRs to identify SBRs that are manually-mislabeled as NSBRs. Security engineers can use the model to automate the classification of BRs from large bug databases to reduce the time that they spend on searching for SBRs. We evaluated the model's predictions on a large Cisco Software system with over ten million source lines of code. Among a sample of BRs that Cisco bug reporters manually labeled as NSBRs in bug reporting, our model successfully classified a high percentage (78%) of the SBRs as verified by Cisco security engineers, and predicted their classification as SBRs with a probability of at least 0.98.
-
Identifying security fault reports via text mining
2009Co-Authors: Michael Gegick, Pete Rotella, Tao XieAbstract:A fault-tracking (bug-tracking) system such as Bugzilla contains fault reports (FRs) collected from various sources such as development teams, test teams, and end-users. Software or security engineers manually analyze the FRs to label the subset of FRs that are security fault reports (SFRs), which indicate a security problem. These SFRs generally deserve higher priority in fault fixing than the not-security fault reports (NSFRs). However, this manual process is time consuming and error-prone (e.g. mislabeling an SFR as an NSFR). To address these important issues, we developed a new approach that applies text mining natural-language descriptions of FRs to train a statistical model on already manually-labeled FRs to identify unlabeled SFRs or SFRs that are manually-mislabeled as NSFRs. A security team can use the model to automate the classification of FRs for large fault databases to reduce the time that they spend on searching for SFRs. We evaluated the model's predictions on a large Cisco Software system with over ten million source lines of code. Among a sample of FRs that Cisco Software engineers manually labeled as NSFRs, our model successfully classified a high percentage (78%) of the SFRs as verified by a Cisco security team, and predicted their classification as SFRs with a probability of at least 0.98. Our results also indicate that a high percentage (77%) of the SFRs identified by our model is associated with Software components that a code-level statistical model predicted to be attack-prone. Such findings provided valuable insights for calling for a future combined approach that exploits both textual information of FRs and code-level information of their associated Software components.
Laurie Williams - One of the best experts on this subject based on the ideXlab platform.
-
ESSoS - Toward Non-security Failures as a Predictor of Security Faults and Failures
Lecture Notes in Computer Science, 2009Co-Authors: Michael Gegick, Pete Rotella, Laurie WilliamsAbstract:In the search for metrics that can predict the presence of vulnerabilities early in the Software life cycle, there may be some benefit to choosing metrics from the non-security realm. We analyzed non-security and security failure data reported for the year 2007 of a Cisco Software system. We used non-security failure reports as input variables into a classification and regression tree (CART) model to determine the probability that a component will have at least one vulnerability. Using CART, we ranked all of the system components in descending order of their probabilities and found that 57% of the vulnerable components were in the top nine percent of the total component ranking, but with a 48% false positive rate. The results indicate that non-security failures can be used as one of the input variables for security-related prediction models.
-
ICST - Predicting Attack-prone Components
2009 International Conference on Software Testing Verification and Validation, 2009Co-Authors: Michael Gegick, Pete Rotella, Laurie WilliamsAbstract:Limited resources preclude Software engineers from finding and fixing all vulnerabilities in a Software system. This limitation necessitates security risk management where security efforts are prioritized to the highest risk vulnerabilities that cause the most damage to the end user. We created a predictive model that identifies the Software components that pose the highest security risk in order to prioritize security fortification efforts. The input variables to our model are available early in the Software life cycle and include security-related static analysis tool warnings, code churn and size, and faults identified by manual inspections. These metrics are validated against vulnerabilities reported by testing and those found in the field. We evaluated our model on a large Cisco Software system and found that 75.6% of the system's vulnerable components are in the top 18.6% of the components predicted to be vulnerable. The model's false positive rate is 47.4% of this top 18.6% or 9.1% of the total system components. We quantified the goodness of fit of our model to the Cisco data set using a receiver operating characteristic curve that shows 94.4% of the area is under the curve.
Goyeneche Cucunuva, Segundo Euriperez - One of the best experts on this subject based on the ideXlab platform.
-
Configuración de la red de una empresa de tecnología, utilizando soluciones integradas LAN/WAN bajo topología Cisco.
Universidad Nacional Abierta y a Distancia UNAD, 2018Co-Authors: Goyeneche Cucunuva, Segundo EuriperezAbstract:El contenido de este documento hace referencia a la temática vista durante el desarrollo del Diplomado de Profundización de Cisco CCNA ofrecido por la UNAD y mediante el cual se demuestra las habilidades adquiridas en diversos aspectos de Networking. Se presenta un escenario con una topología de red distribuida en tres ciudades principales las cuales deben tener comunicación en la red de datos, para ello se configuran los dispositivos Cisco que hacen parte de esta, implementando direccionamiento IP, aplicando los protocolos de enrutamiento necesarios y las configuraciones de seguridad en los Switches y Routers en la Topología propuesta. Para llevar a cabo esta solución se realizó la simulación de la red en la herramienta Software Packet Tracer de Cisco en la cual se implementaron los lineamientos y protocolos requeridos.The content of this document refers to the topics discussed during the development of the Cisco CCNA In-Depth Diploma offered by the UNAD and through which the skills acquired in various aspects of Networking are demonstrated. A scenario is presented with a distributed network topology in three main cities which must have communication in the data network, for this purpose the Cisco devices that are part of it are configured, implementing IP addressing, applying the necessary routing protocols and the Security configurations in the Switches and Routers in the proposed Topology. To carry out this solution, the simulation of the network was performed in the Cisco Software Packet Tracert tool in which the required guidelines and protocols were implemented