Mobile Information Systems

Mobile Information Systems / 2017 / Article
Special Issue

Location-Based Mobile Marketing Innovations

View this Special Issue

Research Article | Open Access

Volume 2017 |Article ID 8501976 | 13 pages | https://doi.org/10.1155/2017/8501976

An Enhancement of Optimized Detection Rule of Security Monitoring and Control for Detection of Cyberthreat in Location-Based Mobile System

Academic Editor: Floriano Scioscia
Received09 Dec 2016
Revised27 Jun 2017
Accepted06 Jul 2017
Published19 Sep 2017

Abstract

A lot of mobile applications which provided location information by using a location-based service are being developed recently. For instance, a smart phone would find my location and destination by running a program using a GPS chip in a device. However, the information leakage and the crime that misused the leaked information caused by the cyberattack of mobile information system occurred. So the interest and importance of information security are increasing. Also the number of users who has used mobile devices in Korea is increasing, and the security of mobile devices is becoming more important. Snort detection system has been used to detect and handle cyberattacks but the policy of Snort detection system is applied differently for each of the different kinds of equipment. It is expected that the security of mobile information system would be improved and information leakage would be blocked by selecting options through optimization of Snort detection policy to protect users who are using location-based service in mobile information system environment in this paper.

1. Introduction

The importance of location-based services (LBS), which is a wired and wireless Internet service utilizing current and past location information of users with terminal which can track location, is emphasized due to the development of mobile communication technology and the rapid spread of mobile terminals [1].

The location-based service is a service that identifies the user’s location using Location Detection Technology and adds related applications. I think it can be used for various purposes, creating added value using application and location information of wired and wireless Internet.

Also, due to the recent development of cyberattack technology, information leakage as hacking and personal information exposure has become a problem. There is a high concern about exposure of personal information to the current location due to the nature of location information services. In the member information exposed through the online site, personal information such as a name, a resident registration number (ID), an address, and a resident registration number may be used for other purposes through theft. Further, the location information of the customer and the identification of the movement trajectory through the location information may already act as direct privacy violation factors. For this reason, concerns about privacy breaches caused by leakage of location-based services are more serious in Korea [24].

The key to security monitoring is rapid detection of cyberattacks. Among the various security monitoring systems, a network-based intrusion detection system (IDS) is the only system that can detect application attacks such as web hacking most efficiently by installing them between the control network entrances. The function of the intrusion detection system (IDS) is to use a pattern matching method that detects an attack and generates an alarm when a header or Payload information communicating through the network is detected as an attack.

However, if an attacker encrypts communication signals due to attack packets or malicious code infections, the intrusion detection system (IDS) only checks the encrypted packets. Even if the attack packet is an actual attack packet, it cannot be detected and waypoint also cannot be detected. In order to detect such an attack, it is necessary to develop a behavior-based detection system that can detect and alert an attack using an unknown attack technique instead of a pattern matching methods [68].

Currently, security monitoring technology analyzes cyberattack techniques and malicious codes, extracts patterns such as certain strings, and then uses this pattern to develop detection patterns (signature) and apply them to intrusion detection systems. After that, if the cyberattack information matches the detection pattern, it is detected as an accident. If the attack technique is changed, the detection pattern should be corrected in a timely manner so as to maintain the optimized state. However, it is not easy to detect new attacks or malicious codes.

In addition, recent cyberattack techniques such as hacking and distribution of malicious code are developing rapidly and utilizing advanced and intelligent techniques such as double encryption technique to prevent detection by security monitoring or vaccine. So it is not enough to completely detect and block new cyberattacks.

Therefore, in order to efficiently detect and respond to cyberattacks in systems that utilize location-based services in mobile information systems, it is necessary to optimize security monitoring detection techniques to share information among security monitoring centers or to standardize detection patterns according to heterogeneous equipment.

2.1. Location-Based Service

LBS is an acronym for location-based service. It is generally defined as an application system and service that accurately grasps the location of a person or object based on the mobile communication network and utilizes it. Accordingly, the LBS is a system that grasps the location information of an individual or a vehicle through a mobile communication base station and a GPS (Global Positioning System) and provides various advanced services based on the information [1].

LBS provides various application services based on location information. These include emergency assistance, location information services, traffic congestion and navigation information, and location-based billing. Other applications include Intelligent Transport Systems (ITS), assistive devices for people with disabilities, L-Commerce based on location information, and cell ID-based friends using cell phones (see Table 1).


SortField of applicationBenefit

(1)Tracking the location of a young or demented elderlyMissing child prevention, accident prevention
(2)Tracking your pet locationLost, accident prevention
(3)Vehicle navigationIdentifying the route of the vehicle
(4)Location of field repEffective management of field rep
(5)Providing information about the current locationNearby information services such as theaters, gas stations, restaurants
(6)Police, security, military vehicle managementCrime prevention
(7)Providing location information of courier and cargoReducing oil, transportation, and communication costs

The current location information acquisition technology of the wireless communication network enables collecting more precise location information by combining the GPS and other location positioning technology and wireless communication network, and it is possible to provide more various application services. As the location information is connected with the mobile communication network, it is possible to provide a general service in the future, and the application service structure provided in the network is changing from a wired/wireless communication network structure with an independent vertical structure to a horizontal structure for wired/wireless integration. Also, all network entities will evolve into an open converged network that provides services based on an equalized All-IP network. Through the development of position location system such as A-GPS (Assistance-GPS) and the paradigm change of ubiquitous and pervasive computing environment, MT (Mobile Terminal) will become a subject of information provision independently and will develop its form to deliver its location information to LBS SP (Service Provider). With these developments, it is necessary to provide the components of location-based services with safety and reliability beyond the conventional wired and wireless network level.

2.2. Intrusion Detection System

Intrusion detection system (IDS) was introduced in 1980 by James Enderson of the United States in a paper called “Computer Security Threat Monitoring and Surveillance.” In 1986, Dorothy Denning published an article entitled “An Intrusion Detection Model” and was influenced by IDS.

Intrusion detection systems can reduce the misuse detection and improve the performance of the system by designing efficient and complete detection rules for cyberthreats. Rules should be as simple and flexible as possible and handle large amounts of network traffic without packet loss. This requires testing procedures to assess the appropriateness before applying the developed rules and periodic optimization to speed up the rules.

For exact detection rules, you must test them before applying them in the intrusion detection system (IDS). Inaccurate rules cause too many false positives and false negatives. A large number of false detection events may cause unnecessary analysis time, prevent detection of normal attack events, or cause the network sensor of the IDS to go down. In order to reduce false detection events, test procedures are required before the system is applied. When testing, efficiency, usability, accuracy, and uniqueness should be considered.

In addition, false positives should be reduced. False positive events occur when you configure detection rules extensively or when you activate unnecessary rules. In order to reduce this, we need to rigorously apply detection rules through precise analysis of the exploit. In addition, it disables the detection rules of the simple information providing format such as “ICMP UNREACH” to reduce the load of the cyberthreat attack event. Inaccurate rules flood false positives and generate false negatives. A large number of false detection events may cause unnecessary analysis time and may prevent detection of cyberthreat attack events.

Until now, the term “security monitoring” has not been defined as a legal rule. In recent years, it has been a step in the process of conceptualization in the academic sense. The term “security control” is used in English as “Security Monitoring” or “Security Monitoring & Control.” The dictionary meaning of “Monitoring” is to protect against various errors that may occur during computer program execution. And the Korean dictionary of the Korean language states that “control” means “to control and control by necessity at a country or an airport” [9] (see Figure 1).

2.3. Intrusion Detection System

The Snort intrusion detection system is one of the most widely used systems among intrusion detection systems (IDS) and is an open source network-based intrusion detection system (open source NIDS) [1214].

The rule is divided into Header and Option. As shown in (Figure 2), detailed rules can be distinguished as conditions to be detected in the detection operation, protocol type, source address, source port, traffic transmission direction, destination IP address, and destination port. The elements used in these detailed rules are summarized as shown in Figure 2.

The Rule Header of Snort is an integral part of the detection rule that includes five elements: Rule Action, Protocol, Source, Destination IP, Source, Destination Port, and Traffic Direction. Rule Action specifies what the rule should do if the packet matches the rule. Snort has rule actions such as “pass, log, alert,” but in most cases it uses the alert Rule Action [1518] (see Table 2).


Snort instruction formatDefinition

Header
 Rule Action
  alertGenerate Alert
  logLeave log
  passIgnore pat
  activateSend alerts and activate dynamic rules
  dynamicIt is activated by the activate rule and the Log option
  dropDrop a packet and leave a log
  rejectConnection terminated and logged
  dropDiscard packets and leave no logs
 Protocol
  tcpTCP protocol support
  udpUDP protocol support
  icmpICMP protocol support
  ipIP protocol support
 IP
  anyAll IP address
  numeric IPSpecific IP addresses
  numeric IP listMultiple IP addresses
  CIDRSpecific network class destination
(i) Class A Network (8 bits)
(ii) Class B Network (16 bits)
(iii) Class C Network (24 bits)
  negation(!)All IP addresses except the specified IP address
 Port
  anyAll port numbers
  static portFixed Port Number
  ranges(:)Port range destination
  negation(!)All ports except the specified port
 Direction
  ->From the origin host to the destination host
  <-Change the source and destination information and specify to “->”
  bidirectional(<>)Bidirectional detection support

Snort’s rule options are divided into General, Payload Detection, and Nonpayload Detection rule options as shown in Table 3.


Snort instruction formatDefinition

Option
 General
  msgMessage to record when Alert or logging
  referenceReferences to additional information
  gidAlert generation module id
  sidUse to distinguish snort detection rules
  revDisplay information about revision of rule with sid
  classtypeInformation that can classify an attack
  priorityShow the importance (priority) of detection rules
 Payload
Detection
  contentSpecific content looking for in the payload of a packet
  content modifier
   nocaseNot classifying capital and small letter
   rawbytesIgnore the decoding process and check the raw packet data
   offsetSpecify whether to start pattern search after the first few bytes of the packet
   depthSpecify how to compare pattern search from offset to how many bytes
   distanceSpecify whether to start pattern after how many bytes from previous pattern matching.
   withinSpecify how to compare pattern searches from distance to how many bytes
   http_client_bodySearch in body part of HTTP request
   http_cookieSearch in the cookie portion of the HTTP header
   http_headerSearch in the HTTP header section
   http_methodSearch in the HTTP methods section
   http_uriSearch in the HTTP URI section
   fast_patternSpecify the pattern to search first
  uricontentRetrieve patterns from URI information in HTTP
  urilenCheck HTTP URI length
  isdataatChecks if the payload has a certain number of bytes
  pcreSearch by regular expression
  byte_testCompare with specific value after specific byte operation
  byte_jumpJump as much as the operation result value after a certain byte operation
  ftpbounceFTP bounce attack detection
  asn1Detect malicious encoding
  cvsDetect invalid Entry string in CVS
  dce_ifaceDetect traffic pattern requesting DCE/RPC
  dce_opnum
  dce_stup_data
 Non-Payload
Detection
  IP
   fragoffsetIP fragment offset field check
   fragbitsIP fragment offset field check
   tosIP Service type field check
   idIP identification field check
   ttlIP Time To Live field check
   ip_protoIP protocol inspection
   ipoptsIP Options field check
  TCP
   seqTCP sequence number check
   ackTCP acknowledge number check
   flagsTCP flag bit field check
   windowTCP window size check
  ICMP
   itypeICMP type check
   icodeICMP code check
   icmp_idICMP identification check
   icmp_seqICMP sequence number check
  dsizeDetect the payload size of packets to detect abnormal size packets
  flowDefines the direction of the packet in relation to the client-server communication stream
  flowbitsOptions to support session-based detection
  rpcrpc service identification
  sameipCheck if origin and destination IP are the same
  stream_sizeCheck the size of the session according to the TCP sequence number
 Thresholding
  limitOnly the first warning occurs when multiple identical events occur within a certain time
  thresholdAlert when the number of the same events that occur within a certain time is exceeded

3. Optimization of Selected Snort-Based Detection Rule

3.1. Header Detection Rule Optimization

In Rule Action, “alert” generates a warning, “log” leaves a log, “pass” ignores the packet, “activate” sends a warning and activates the specified dynamic rule, and “drop” throws away the packet and leaves a log. Also “reject” leaves the connection and log, and “sdrop” discards the packet and leaves no log. Of these, 6 items including “log,” “pass,” “activate,” “dynamic,” “reject,” and “sdrop” are excluded. For this reason, “log” and “pass” are options for packet logging or packet ignoring. “Activate” and “dynamic” are used mainly for additional logging after detection of attack. They are not suitable for the purpose of notifying the occurrence of attack. “Reject” and “sdrop” are excluded because they are additional actions after interception.

In the protocol, “tcp,” “udp,” “icmp,” and “ip” support the TCP, UDP, ICMP, and IP protocols, respectively. In the protocol, “tcp” supports the TCP protocol, “udp” supports the UDP protocol, “icmp” supports the ICMP protocol, and “ip” supports the IP protocol (see Table 4).


Command format Selection of detection rule standardization

Rule ActionalertGenerate a warning
dropDrop the packet and leave a log

ProtocoltcpTCP protocol support
udpUDP protocol support
icmpICMP protocol support
ipIP protocol support

Command format Excluded detection rules standardized/excluded reasons

Rule ActionlogLoggedIt is an option for packet logging or packet override, which is mainly used for logging after attack detection, but it is for the purpose of notifying the occurrence of an attack
passIgnore packets
activateSend an alert and activate the specified dynamic ruleThis option is used for additional logging after detection of an attack, but it is consistent with the purpose of notifying the occurrence of the attack
dynamicIt is activated by the activate rule and acts like the log option
rejectConnection terminated and loggedAdded after Intrusion rrevention and exclude as action
sdropDiscards packets and leaves no logs

In IP, “any” represents All-IP address targets, “numeric IP” represents a specific IP address target, “numeric IP list” supports up to 10, including CIDR among multiple IP addresses, “CIDR” represents the length object of a specific network address, and “negation(!)” represents All-IP address destinations except the specified IP address. In port, “any” represents all port number targets, “static port” represents fixed port number targets, “ranges(:)” represents port range targets, and “negation(!)” represents all port destinations except for specified ports. In Direction, “-> option” indicates the direction of the destination host from the source host, and “<> option” indicates the direction of both the source host and the destination host. The <- option lowers the detection efficiency by generating a lot of intrusion detection sensor load. Also, “<-” is to remove the mandatory option because it is necessary to use the -> option by changing the source IP and destination IP (see Table 5).


Command format Selection of detection rule standardization

IPanyAll IP address
numeric IPSpecific IP addresses
numeric IP listMultiple IP address up to 10 including CIDR
CIDRThe length of a specific network address.

Portanyall port numbers
static portFixed Port Number
ranges(;)Port range destination

Direction->Direction from the origin host to the destination host
<>Origin host and destination host bidirectional

Command format Excluded detection rules standardized/excluded reasons

Direction<-Source Host and Destination Host ReverseIt is excluded because it can be made by changing source IP and destination IP and generate load

3.2. General Rule Optimization

In General, “msg” is used as an option to indicate a message to be recorded when detecting security control events. “Reference” is a reference to additional information, “gid” is the ID of the alert generation module, sid is used to identify the Snort detection rule, “<100” is the number reserved for future use, “100–1,000,000” indicates the number assigned by Snort, and “>1,000,000” represents a user-defined rule assignment number. “Rev” keyword indicates information about the revision of the sid, “classtype” identifies information that can classify the attack, and “priority” indicates the importance of the rule. In General, all options excluding “msg” are excluded. The “reference” case is excluded as an additional option for reference of detection rule information. “Gid” and “sid” are excluded from Snort configuration module as indicating module ID and detection rule ID that generated warning. Also, “rev” is excluded as an option for version control of detection rules, and “classtype” and “priority” are excluded due to lack of usability as an option for sorting and prioritizing detection rules (see Table 6).


Command format Selection of detection rule standardization

GeneralmsgMessage to record when detecting

Command format Excluded detection rules standardized/excluded reasons

GeneralreferenceReferences to additional informationExcluded as an additional option for reference of detection rule information
gidAlert generation module idExcept for the module ID of the configuration module and the ID of the detection rule (Snort-specific function)
sidUse to distinguish Snort detection rules
<100 reserved number for future use
100–1,000,000 number assigned by Snort
>1,000,000 custom rule assignment numbers
revInformation on revision of rules with sidExcluded as an option for versioning of detection rules
classtypeInformation that can classify an attackExcluded as an option for risk display and classification of detection
prioritySignificance of detection rules (top/middle/bottom)Exclude as an option for indicating the importance of detection rules

3.3. Payload Detection and Nonpayload Detection Rule Optimization

In Payload Detection (Content, Content Modifier), “content” indicates the specific content to be found in the Payload of the packet, and “nocase” means not case sensitive. “Rawbytes” ignores the decoding process and indicates raw packet data inspection, offset indicates the pattern search start position, depth indicates the pattern search range, distance indicates a new pattern search start position after the previous pattern matching, and within indicates the pattern search range. The http_client_body searches in the body part of the HTTP request. The http_cookie searches in the cookie part of the HTTP header. The http_header searches in the HTTP header part. The http_method searches in the HTTP method part. The http_uri part searches the HTTP URI part in the fast_pattern Eye. This is the command to designate the pattern to search first. However, HTTP related commands can be specified with the content option and can be excluded. Fast_pattern excludes string matching as a priority (see Table 7).


Command formatSelection of detection rule standardization

Payload DetectioncontentSpecific content to look for in the payload of a packet
nocaseCase insensitive
rawbytesIgnore the decoding process and check raw packet data
offsetPattern search start position (after the first few bytes of the packet)
depthPattern search range (compare pattern search from offset to several bytes)
distanceNew pattern search start position after a previous pattern match (after a few bytes)
withinPattern search range (compare pattern search from distance to several bytes)

Command formatExcluded detection rules standardized/excluded reasons

Payload Detectionhttp_client_bodySearch in body part of HTTP request Except for the content option
http_cookieSearch in the cookie portion of the HTTP header
http_headerSearch in the HTTP header section
http_methodSearch in the HTTP methods section
http_uriSearch in the HTTP URI section
fast_patternSpecify the pattern to search firstExcluded as string matching from specified priority

In Payload Detection, “uricontent” searches patterns from URI information of HTTP, “urilen” checks HTTP URI length, and “isdataat” searches whether Payload has a certain number of bytes. “Pcre” searches for a regular expression, byte_test compares it to a specific value after a certain byte operation, and “byte_jump” jumps to a result value after a certain byte operation. “Ftpbounce” detects an FTP bounce attack, “asn1” detects a malicious encoding, and “cvs” detects an invalid entry string in CVS. Also, “dce_iface,” “dce_opnum,” and “dce_stup_data” detect the DCE/RPC request traffic pattern. Of these, “urilen” is excluded because it can be specified using mandatory options, and “ftpbounce,” “asn1,” “cvs,” “dce-iface,” “dce-opnum,” and “dce_stup_data” commands should be excluded because these are the options for detecting specific attacks on specific services (see Table 8).


Command format Selection of detection rule standardization

Payload Detection
isdataatCheck if the payload has a certain number of bytes
pcreSearch by regular expression
byte_testCompare with specific value after specific byte operation
uricontentSearch patterns from URI information in HTTP

Command format Excluded detection rules standardized/excluded Reasons

Payload DetectionurilenCheck HTTP URI lengthExcluded as assignable opting using mandatory option
ftpbounceFTP bounce attack detectionExcluded as assignable opting using mandatory option
asn1Detect malicious encoding
cvsDetect invalid Entry String in CVS
dce_ifaceDCE/RPC request traffic pattern detection
dce_opnum
dce_stup_data

Among the Nonpayload Detection options, the commands related to IP such as fragoffset, fragbits, tos, id, ipopts, and TCP related commands seq, ack, and windows are excluded because they are not useful in creating detection rules (see Table 9).


Command format Selection of detection rule standardization

Nonpayload Detection (IP)ttlInspect IP Time-To-Live field
ip_protoInspect IP protocol field

Nonpayload Detection
(TCP)
flagsInspect TCP flag bit field

Nonpayload Detection
(ICMP)
itypeInspect ICMP type
icodeInspect ICMP code
icmp_idInspect ICMP identification field
icmp_seqInspect ICMP sequence number

Command format Excluded detection rules standardized/excluded reasons

Nonpayload Detection (IP)fragoffsetInspect IP fragment Offset fieldIt is excluded through consultation with related companies, Because it is not useful in creating detection rule
fragbitsCheck whether IP fragmentation and reserved bits are set
tosInspect IP Service type field
idInspect IP identification field
ipoptsInspect IP Options field
Nonpayload Detection (TCP)seqInspect TCP Sequence number
ackInspect TCP acknowledge number
windowInspect TCP window size

In Nonpayload Detection, “dsize” checks packet payload size to detect packets of abnormal size, and “flow” defines packet direction in relation to client-server communication stream. “Flowbits” is an option to support session-based detection, and “Rpc” acts to identify the rpc service but it is excluded because it can be specified using mandatory options. The “sameip” checks whether the source and destination IPs are the same, and the “stream size” checks the size of the session according to the TCP sequence number, but it is excluded because it can be specified through the “dsize” option. In Rule Thresholds, “Limit” indicates the first occurrence of a warning when a number of identical events occur within a certain time, and “Threshold” indicates a warning when the number of the same events occurring within a certain time exceeds the corresponding number. Threshold option was used before Snort 2.8.5 version; Snort 2.8.5.1 or later uses Detection Filter or Event Filters option (see Table 10).


Command format Standardization of detection rules Candidates for selection

Nonpayload DetectiondsizePacket detection of abnormal size by checking the packet’s payload size
flowDefines the direction of the packet in relation to the client-server communication stream
flowbitsOptions to support session-based detection

Rule ThresholdsLimitAlert for the first time when multiple identical events occur within a certain time
ThresholdAlert when the number of the same events that occur within a certain time is exceeded

Command format Excluded detection rules standardized/excluded Reasons

Nonpayload DetectionrpcIdentify the rpc serviceIt identifies the rpc service, but it can be specified using mandatory options. It can be specified through the dsize option.
sameipCheck if origin and destination IP are the same
stream sizeCheck the size of the session according to the TCP sequence number

4. Comparison Analysis of Existing Snort Detection Options

Optimizing the existing Snort detection grammar will allow the user to understand and analyze the wrong type of policy created without considering the performance and false positives of the detection sensor in the event of a vulnerability attack. Also this can elaborate detection rules. In order to normalize the detection rules; first, if short strings are applied, frequent detection of the intrusion detection system sensor occurs, thereby degrading the performance of the intrusion detection system sensor. Therefore, it is necessary to create a policy that detects a string of at least 4 bytes or more. Second, when a communication string is detected frequently, a large number of detection events are generated, which may cause a false alarm, and the performance of the detection sensor may be reduced, thereby limiting communication traffic in a typical Internet environment. Third, in the PCRE grammar,  . (Dot), (Asterisk) is a special character that matches any string. Because this matching matches all strings in the packet Payload, the PCRE computation consumes a lot of system resources and leaks from the intrusion detection system sensor. Fourth, if the setting value exceeds the detection string length limit of the intrusion detection system sensor, it may cause a problem that it cannot be detected. In addition, long length PCRE matching causes performance load of the intrusion detection system sensor. Fifth, when searching a continuous pattern of the same character, a looping phenomenon may occur as repeated operations are performed, which causes a heavy load on the CPU usage. Therefore, there is a purpose to improve these five problems by optimizing Snort detection grammar (see Table 11).


Detection rule optionsSnortDetection rule
optimization grammar selection

Header (24/17)
 Rule Actions (8/2)
  alertOO
  logOX
  passOX
  activateOX
  dynamicOX
  dropOO
  rejectOX
  sdropOX
 Protocols (4/4)
  tcpOO
  udpOO
  icmpOO
  ipOO
 IP (5/5)
  anyOO
  numeric IPOO
  numeric IP listOO
  CIDROO
  negation(!)OO
 Port (4/4)
  anyOO
  static portOO
  ranges(:)OO
  negation(!)OO
 Direction (3/2)
  ->OO
  <-OX
  bidirectional(<>)OO
Option (47/24)
 Meta Data (6/1)
  msgOO
  referenceOX
  sidOX
  revOX
  classtypeOX
  priorityOX
 Payload Detection (19/12)
  contentOO
  content modifier
   NocaseOO
   RawbytesOO
   DepthOO
   OffsetOO
   DistanceOO
   WithinOO
   http_client_bodyOX
   http_uriOX
  http_headerOX
  http_cookieOX
  uricontentOO
  isdataatOO
  pcreOO
  byte_testOO
  byte_jumpOO
  ftpbounceOX
  asn1OX
  regexOX
 Non Payload Detection (20/9)
  fragoffsetOX
  ttlOO
  tosOX
  idOX
  ipoptsOX
  fragbitsOX
  dsizeOO
  flagsOO
  flowOO
  flowbitsOO
  seqOX
  ackOX
  windowOX
  itypeOO
  icodeOO
  icmp_idOO
  icmp_seqOO
  rpcOX
  ip_protoOX
  sameipOX
 Thresholding (2/2)
  limitOO
  thresholdOO

5. Conclusion

The purpose of this paper is to find a detection rule optimization method for protecting users who use location-based services in mobile information systems and proving the compatibility of detection rules between different intrusion detection systems (IDS/IPS) introduced in each security control center (cybersafety center) based on IDS Snort in order to prepare for new cyberthreats and cyberattacks.

Recent hacking technologies understand cyberattack packet contents in order to detect new cyberthreats that are developing rapidly and present the best intrusion detection rules for network environment. Based on the Snort detection rules, we designed the models and options of the essential detection rules and suggested the most optimized detection rule production standards through understanding and analyzing the wrong policies such as the performance of the detection sensor and the policy that does not consider the false positives. In this paper, we propose an efficient detection and countermeasure of new cyberattacks through the Snort-based detection rule standard requirements. Also, constructing a standardized security management system of the heterogeneous intrusion detection system by maintaining the optimization state by correcting and revising the detection pattern according to the actual situation of each security control center is possible.

This standardization of integrated intrusion detection pattern is expected to establish an efficient operation system of each security control center (cybersafety center) performing security control.

Conflicts of Interest

The authors declare that they have no conflicts of interest.

References

  1. A. Dey, J. Hightower, E. De Lara, and N. Davies, “Location-based services,” IEEE Pervasive Computing, vol. 9, no. 1, pp. 11-12, 2010. View at: Publisher Site | Google Scholar
  2. R. Bejtlich, “The practice of network security monitoring: understanding incident detection and response,” No Starch Press, pp. 2–20, 2013. View at: Google Scholar
  3. J. S. Hong, Y. H. Lim, W. H. Park, and K. H. Kook, “Improved Security Monitoring and Control Using Analysis of Cyber Attack in Small Businesses,” The Journal of Society for e-Business Studies, vol. 19, no. 4, pp. 195–204, 2014. View at: Publisher Site | Google Scholar
  4. W. Park and S. Ahn, “Performance Comparison and Detection Analysis in Snort and Suricata Environment,” Wireless Personal Communications, vol. 94, no. 2, pp. 241–252, 2016. View at: Publisher Site | Google Scholar
  5. T. Xu and Y. Cai, “Feeling-based location privacy protection for location-based services,” in Proceedings of the 16th ACM Conference on Computer and Communications Security (CCS '09), pp. 348–357, ACM, Chicago, Ill, USA, November 2009. View at: Publisher Site | Google Scholar
  6. M. Roesch, Snort: Lightweight Intrusion Detection for Networks, vol. 229, Stanford Telecommunications Inc, Santa Clara, Calif, USA, 1999.
  7. Y.-H. Kim and W. H. Park, “A study on cyber threat prediction based on intrusion detection event for APT attack detection,” Multimedia Tools and Applications, vol. 71, no. 2, pp. 685–698, 2014. View at: Publisher Site | Google Scholar
  8. M. Roesch, Snort: Lightweight Intrusion Detection for Networks, vol. 229, Santa Clara, Calif, USA, Stanford Telecommunications, Inc, 1999.
  9. Z. Zhou, Z. Chen, T. Zhou, and X. Guan, “The study on network intrusion detection system of snort,” in Proceedings of the 2nd International Conference on Networking and Digital Society, lCNDS 2010, pp. 194–196, Wenzhou, China, May 2010. View at: Publisher Site | Google Scholar
  10. M. Norton and D. Roelker, SNORT 2.0: Hi-Performance Multi-Rule Inspection Engine, Sourcefire Network Security Inc, 2002.
  11. P. Garcia-Teodoro et al., Anomaly-Based Network Intrusion Detection: Techniques, Systems and Challenges, computers &amp; security 28.1, 2009.
  12. G. C. Tjhai, M. Papadaki, S. M. Furnell, and N. L. Clarke, “Investigating the problem of IDS false alarms: An experimental study using Snort,” IFIP International Federation for Information Processing, vol. 278, pp. 253–267, 2008. View at: Publisher Site | Google Scholar
  13. J. D. Rance, Structured Exception-Handling Methods, Apparatus, and Computer Program Products, Los Gatos, Calif, USA.
  14. S. Chakrabarti, M. Chakraborty, and I. Mukhopadhyay, “Study of snort-based IDS,” in Proceedings of the International Conference and Workshop on Emerging Trends in Technology 2010, ICWET 2010, pp. 43–47, ind, February 2010. View at: Publisher Site | Google Scholar
  15. B. Caswell, J. Beale, and A. Baker, Snort IDS and IPS Toolkit, Syngress, New York, NY, USA, 2007.
  16. D. Burks, Security Onion: Peel Back the Layers of Your Network in Minutes, Software Engineering Institute, January 2014.
  17. A. Deuble, Detecting and Preventing Web Application Attacks with Security Onion, SANS Institute 4.1, 2012.
  18. P. Wonhyung, Requirements of Detection Rules in Intrusion Detection System based on SNORT, Telecommunications Technology Association in South Korea, 2015.

Copyright © 2017 Wonhyung Park and Byeong Ho Kang. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.


More related articles

949 Views | 246 Downloads | 0 Citations
 PDF  Download Citation  Citation
 Download other formatsMore
 Order printed copiesOrder

Related articles

We are committed to sharing findings related to COVID-19 as quickly and safely as possible. Any author submitting a COVID-19 paper should notify us at help@hindawi.com to ensure their research is fast-tracked and made available on a preprint server as soon as possible. We will be providing unlimited waivers of publication charges for accepted articles related to COVID-19. Sign up here as a reviewer to help fast-track new submissions.